Инженерные заметки Naly: Polymarket Gamma как воспроизводимый слой снимков рынка

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

Аннотация

Polymarket Gamma API следует рассматривать как источник Naly для обнаружения рынков и получения метаданных, а не как торговый интерфейс. Официальная документация Polymarket отделяет Gamma от Data и CLOB API: Gamma охватывает события, рынки, теги, серии, спортивные метаданные, поиск, комментарии и публичные профили, тогда как CLOB отвечает за книги заявок, цены, спреды и аутентифицированные торговые операции. Для статей Naly эта граница полезна. Большинству редакционных рабочих процессов нужны текст вопроса, идентичность рынка, метки исходов, отображаемые вероятности, категорийные теги, дедлайны и контекст разрешения до того, как понадобятся тиковые детали книги заявок.

Тезис этой заметки состоит в том, что Naly должен загружать Gamma в версионируемый слой снимков рынка. Снимок — не истина; это наблюдаемое публичное состояние рынка в конкретный момент времени, привязанное к исходным URL и сохраненным необработанным payload. Это позволяет Naly публиковать то, что другие скрывают: рыночный контекст, ограничения сигнала и точные доказательства, использованные при генерации статьи.

Где это находится в Naly

Загрузка Gamma стоит перед генерацией статей и после обнаружения внешних источников. В издательском контуре Naly она предоставляет часть пакета доказательств со стороны рынка прогнозов для четырех последующих применений:

Обзорам неверных оценок нужны актуальные кандидаты событий и рынков с достаточными метаданными, чтобы сравнивать подразумеваемые рынком вероятности с рассуждением, подкрепленным источниками.
Прогнозным статьям по KBO нужны спортивные рынки, теги команд или событий, дедлайны событий и метки исходов, которые можно отрисовать без ручного ввода рыночного контекста.
Для ссылок на источники нужны стабильные URL рынков, слаги событий и идентификаторы рынков, чтобы читатель мог проверить, почему статья обсуждала конкретный контракт.
Для проверки прогнозов нужны исторические снимки, чтобы последующее разрешение можно было оценить относительно вероятности, которую Naly действительно видел на момент публикации.

Факты о локальной среде выполнения важны в основном для формы, а не для новизны. TypeScript 5.9 и tsx хорошо подходят для скриптов загрузки; drizzle-orm с @neondatabase/serverless может сохранять нормализованные записи и необработанный JSON; Next.js 16 и React 19 могут отрисовывать итоговые страницы статей; пакеты ai и Claude SDK могут использовать подготовленный пакет доказательств только после того, как загрузка сделала состояние рынка явным.

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

Надежный цикл загрузки Gamma состоит из шести этапов.

Обнаружение. Используйте события Gamma, когда Naly нужен широкий поиск активных рынков, и используйте слаги рынков или событий, когда статья привязана к известному URL Polymarket. Руководство Polymarket по рыночным данным рекомендует события для полного активного обнаружения, потому что события включают связанные рынки и сокращают число API-вызовов. Для категорийной работы, например спорта, теги и спортивные метаданные должны сужать обход до ранжирования кандидатов.
Пагинация. Gamma поддерживает как endpoint-ы со смещением, так и keyset endpoint-ы. Для крупного или повторяющегося обхода keyset-пагинация безопаснее, потому что next_cursor становится токеном продолжения, а offset явно отклоняется на keyset endpoint-е рынков. Для небольших целевых задач по статьям пагинация со смещением все еще может быть приемлемой, когда окно запроса узкое, а результат сразу сохраняется как снимок.
Нормализация. Главное правило нормализации состоит в том, что метки исходов и цены исходов должны сопоставляться по позиции. Обзор рыночных данных Polymarket документирует массивы outcomes и outcomePrices как взаимно однозначные массивы, поэтому дисциплина индексов важна. Перепутанный массив — не косметическая ошибка; он переворачивает рыночную интерпретацию статьи.
Создание снимков. Храните и нормализованные колонки, и необработанный JSON. Нормализованные колонки должны включать провайдера, временную метку получения, id или слаг события, id или слаг рынка, текст вопроса, condition id при наличии, идентификаторы токенов при наличии, метки исходов, цены исходов, флаги active и closed, время окончания, теги, source URL и хеш payload. Необработанный JSON защищает Naly от дрейфа схемы и позволяет проверке воспроизвести точный артефакт загрузки.
Оценка кандидатов. Задачи статей должны ранжировать рынки по редакционным критериям, а не по критериям торгового исполнения: свежесть, объем или ликвидность при наличии, близость разрешения, доступность источников, соответствие категории и способность рынка дать понятный читателю контраст. Оценка кандидатов никогда не должна подразумевать, что рыночная цена автоматически неверна; она должна помечать рынок как достойный исследования.
Привязка публикации. Когда сгенерированная статья цитирует рынок, она должна ссылаться на сохраненный snapshot id, исходный URL Polymarket и набор внешних доказательств, использованный автором. Это разница между страницей, которая говорит, что рынок был 62 percent, и страницей, которая может доказать, когда, где и из какого payload появилось это значение.

Лимиты запросов — часть механизма. Polymarket документирует throttling, применяемый Cloudflare, и конкретные лимиты Gamma для /events, /markets, /tags, и /public-search. Naly не нужно приближаться к этим лимитам для ежедневной публикации, поэтому правильная позиция консервативна: ограниченная параллельность, повторные попытки с jitter, хеши payload для идемпотентности и оповещения, когда задача получает throttled, пустые или структурно неожиданные ответы.

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

Недавняя работа на arXiv поддерживает дизайн snapshot-first. Jia et al. описывают данные децентрализованных рынков прогнозов как фрагментированные между off-chain метаданными, записями сделок на уровне исполнений и событиями oracle-разрешения, а затем выступают за единую реляционную систему с разрешением идентификаторов, инкрементальными обновлениями и механизмами согласованности. У меньшей издательской системы Naly та же категория проблемы: одних рыночных метаданных недостаточно, если позже их нельзя связать с ценами, утверждениями статей и итогами разрешения.

Калибровочное исследование Le напрямую относится к языку статей. Используя большие наборы данных Kalshi и Polymarket, статья утверждает, что калибровка зависит от домена, горизонта и эффектов размера сделки; потребители, которые принимают цены за вероятности по номиналу, могут систематически неверно их интерпретировать. Для Naly это означает, что статья должна говорить подразумеваемая рынком вероятность, наблюдаемая цена или публичный рыночный сигнал, а не истина. Статья может обсуждать возможную неверную оценку только после отделения сырого рыночного наблюдения от модели Naly или рассуждения, подкрепленного источниками.

Статья Dubach о микроструктуре Polymarket в основном посвящена данным книги заявок, но она дает полезное предупреждение для дизайна загрузки: у высокочастотных рыночных доказательств есть специфичные для источника режимы ошибок, задержки загрузки и важные соединения данных. Gamma менее гранулярен, чем потоки книги заявок, но действует тот же принцип. Источник числа должен быть видимым. Снимок Gamma, midpoint CLOB и запись сделки on-chain связаны, но не взаимозаменяемы.

Madrigal-Cianci, Monsalve Maya и Breakey описывают рынки прогнозов как байесовские обратные задачи, где наблюдаемые истории вероятностей и объемов шумны, эндогенны и формируются разнородными типами трейдеров. Это усиливает редакционную позицию Naly. Загруженное состояние рынка — это доказательство, а не вердикт. Хорошая инженерия делает эту неопределенность доступной для проверки, а не сглаживает ее во время генерации.

Проектные компромиссы

Gamma против CLOB — первый компромисс. Gamma дает Naly обнаруживаемость, контекст статьи и метаданные. CLOB дает более точное ценообразование и механику книги заявок. Для ежедневных инженерных статей и обзоров рынков прогнозов Gamma должен быть входом по умолчанию, потому что он отвечает, о чем рынок. CLOB можно добавить, когда статье нужна точность спреда, midpoint или истории цен.

Загрузка сначала события или сначала рынка — второй компромисс. Event-first дешевле для широких сканов, потому что событие может содержать несколько рынков и общие метаданные. Market-first чище для проверки, потому что итоговая оценка привязывается к конкретному бинарному исходу. Naly должен загружать обе формы, но делать так, чтобы ссылки в статье указывали на утверждение уровня рынка всякий раз, когда оценивается один исход.

Необработанный JSON против типизированной схемы — третий компромисс. Один только необработанный JSON легко хранить, но трудно безопасно запрашивать. Одни только типизированные колонки легко запрашивать, но они хрупки, когда поля провайдера эволюционируют. Долговечный паттерн — оба варианта: типизированные поля для ранжирования, отрисовки и соединений; необработанные payload для аудита, воспроизведения и миграции.

Живой рендер против замороженного рендера — четвертый компромисс. Живой рыночный виджет может быть полезен, но утверждения статьи должны привязываться к снимку на момент публикации. Иначе старая статья может молча менять смысл, когда Polymarket двигает, закрывает или разрешает рынок. Для стратегии доверия Naly замороженное доказательство лучше свежести, когда страница делает датированное утверждение.

Режимы отказа

Самый опасный отказ — несоответствие исходов и цен. Если метки Yes и No разбираются отдельно от цен, статья может инвертировать сигнал и при этом выглядеть правдоподобно.

Второй отказ — повторное использование устаревшего рынка. Рынок может быть активным во время обнаружения и закрыться к моменту публикации. Каждая задача статьи должна повторно проверять поля active, closed, archived и end-time непосредственно перед привязкой снимка.

Третий отказ — неоднозначность нескольких рынков. Событие Polymarket может содержать несколько торгуемых рынков. Обзор может цитировать событие, но запись проверки должна цитировать конкретный рынок и исход, который оценивал Naly.

Четвертый отказ — дрейф схемы. Публичные API меняют имена полей, значения по умолчанию и вложенные связи. Хранилище снимков должно включать хеши payload, версию парсера, URL провайдера и ошибки валидации, чтобы дрейф был наблюдаемым.

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

Шестой отказ — потеря цитирования. Если статья хранит только отрендеренный markdown, последующая проверка не сможет доказать, какая рыночная страница и какой payload поддерживали утверждение. Соединения статья-рынок должны быть первоклассными записями, а не встроенной прозой.

Заметки по реализации

Практическая реализация Naly может держать контракт загрузки небольшим:

provider: polymarket-gamma.
provider_url: точный endpoint Gamma или публичный URL рынка, использованный для обнаружения.
fetched_at: серверная временная метка в UTC.
event_key и market_key: стабильные идентификаторы или слаги провайдера.
question: канонический текст вопроса рынка.
outcomes: упорядоченные метки.
outcome_prices: упорядоченные десятичные строки, нормализуемые в числовые значения только после валидации.
status: флаги active, closed, archived и publishability.
raw_payload: полный ответ провайдера.
payload_hash: детерминированный хеш для идемпотентности и воспроизведения.
parser_version: кодовый контракт, который интерпретировал payload.

Генератор статей должен получать это как структурированное доказательство, а не как свободный текст prompt. Затем он может создавать markdown через существующий AI-стек, отрисовывать его через pipeline сайта и сохранять цитирования, привязанными к записям источников. Рабочий процесс проверки позже может соединить рыночный снимок статьи с данными разрешения и оценить, насколько хорошо опубликованное утверждение выдержало время.

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