Інженерні нотатки Naly: інгестування API Polymarket Gamma для статей про ринки прогнозів

КороткоNaly інгестує Gamma API Polymarket як детермінований шар відкриття й ціноутворення для всіх робочих процесів ринків прогнозів, замінюючи точкові новинні скрейпи на структуровані ринкові сутності. Щоразу воно перетворює поточні події та ринки на сигнали, готові для статей про помилкове ціноутворення, прев’ю KBO, пакети цитувань і подальшу перевірку результатів, щоб процес написання сюжету завжди стартував із публічно спостережуваних ймовірностей і ринкової структури, а не з припущень.

Анотація

Naly використовує дані ринків прогнозів як інфраструктуру, а не як накладку, тому редакційні артефакти безпосередньо прив’язуються до зовнішнього стану ринку, який можна буде перевірити пізніше. API Gamma дає шлях читання подій, ринків, тегів і цін без потреби в ключах на рівні гаманця. Виклик дизайну полягає в тому, щоб залишити цей шар інгесту достатньо строгим для надійності й водночас достатньо гнучким для редакцій, яким потрібне швидке відкриття тем.

Де це знаходиться в Naly

Інтеграція Polymarket Gamma стоїть на апстрім межі між сирими ринковими примітивами та публікуваними редакційними матеріалами. Це перший крок ширшого пайплайну:

Рівень вхідних даних: отримувати події, ринки, теги та статуси ринків із Gamma.
Рівень інтерпретації: нормалізувати у внутрішню схему Naly (event_id, market_id, ідентифікатори токенів, результати, ймовірності, позначки часу, прапорці active/closed).
Рівень побудови наративу: передавати нормалізовані вхідні дані до потоків складання статей про помилкове ціноутворення й чернеток прогнозів KBO.
Рівень валідації: зберігати стан ринків resolved/closed для подальшої перевірки правдивості статей і ретроспективних scorecards.

Станом на 10 червня 2026 року це особливо узгоджується з активними тактиками, яким потрібні надійні, готові до цитування докази прогнозування: прозорість калібрування, повторюване джерело контенту та подальші робочі процеси верифікації.

Технічний механізм

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

Naly може реалізувати надійний щоденний потік лише з публічних ендпоінтів:

Знаходити активні кандидатні ринки через GET /events з active=true, closed=false, пагінацію (limit, offset), і необов’язкові фільтри замовлення.
Розширювати до складових ринків через payload-и подій, адже події несуть пов’язані ринки та зменшують кількість API-викликів порівняно з окремими запитами ринків.
Цілити в точні сутності за допомогою запитів по slug, коли подія або ринок уже відомі.
Нормалізувати ціни шляхом відображення outcomes та outcomePrices масивів індекс за індексом у іменовані ймовірності.
Зберігати артефакти аудиту як нормалізовані рядки й сирі знімки, щоб кожну статтю можна було простежити до кожної взятої цифри.
Гейтувати подальшу генерацію за свіжістю + перевіркою схеми; застарілі або неповні знімки позначаються для оновлення перед використанням.

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

На практиці мінімальний запис джерела правди для Naly має містити:

ідентифікатори події та ринку
ринок question
clobTokenIds (для подальшого узгодження ціни з CLOB за потреби)
outcomes та outcomePrices
enableOrderBook
active, closed, а також часові поля (позначки початку/закінчення)
позначка часу отримання та URL джерела

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

Що кажуть дослідження

Дослідження ринків прогнозів підтримують цей підхід data-first, але додають запобіжники навколо інтерпретації.

Модель ринкових даних у ринках прогнозів корисна лише за умов налаштованої калібрування й коректної інтерпретації; ціни не є універсальними ймовірностями без контексту. Дослідження 2026 року щодо Polymarket і Kalshi виявило системні патерни калібрування, що змінюються залежно від домену та горизонтів, зокрема вимірюване недостатнє упевненість у певних сферах.
Інше дослідження 2026 року з акцентом на життєвий цикл підкреслює, що змістовний аналіз ринку вимагає синхронізованої багаторівневої інженерії даних: метадані ринку, торгові події та сигнали врегулювання мають мати явний зв’язок і періодичні перевірки консистентності, а не бути ізольованими витягами.
Ранні роботи з мікроструктури ринку показують, що ціни ринку транслюють інформацію трейдерів за стилю потоку безперервного аукціону, тому Naly може розглядати ринкові ціни як сигнали колективного прогнозу, водночас перевіряючи результати з часом.
Література з прогнозування, яка порівнює ринкові ціни з іншими методами (наприклад, опитувальними), показує, що ринки прогнозів можуть бути дуже інформативними, але лише за умови збереження верифікації результатів і дисципліни моделі.

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

Компроміси проектування

Naly свідомо оптимізує інгестування на користь надійності, а не швидкості.

Gamma-only проти Gamma+CLOB: Gamma дає стабільне відкриття та публічний контекст швидко; додавання CLOB підвищує насиченість мікроструктури, але додає складність з авторизацією й ендпоінтами.
Щоденний знімок проти безперервного стрімінгу: детермінований запланований pull легше аудитувати та відтворювати, ніж безперервні стріми, але пропускає зміни усередині хвилини.
Витяг за подією проти витягу за ринком: event-first зменшує дублікати викликів і покращує контекстне охоплення; market-first дає трохи менший розмір payload для вузьких завдань.
Широка схема проти жорсткої схеми: широка схема JSON-first швидше інтегрується, але підвищує ризик дрейфу схеми; жорстка нормалізація ловить дрейф раніше, але збільшує накладні витрати на міграцію.
Узагальнені поля проти доменно-специфічних полів: використання спільних полів покращує повторне застосування між статтями; додавання доменно-специфічних розширень (наприклад, вікон упевненості для спорту) підвищує точність негайно, але може фрагментувати довгострокове супроводження.

З огляду на мету Naly — довіру користувачів і утримання — сувора відтворюваність і якість цитувань мають переважати над оптимізацією латентності в короткостроковій перспективі.

Сценарії відмов

Найбільші сценарії відмов — операційні, а не алгоритмічні.

Відсутні дані через помилки пагінації: якщо limit та offset вікна змінюються між опитуваннями, можуть з’являтися дублікати чи прогалини. Пом’якшення: checkpoint-ити курсори пагінації та забезпечувати idempotent upserts.
Втрата історичного контексту: closed=false open-market pull-и опускають закриті елементи, якщо не запитано явно. Пом’якшення: запуск окремого історичного backfill-шляху для задач верифікації. closed=true нестабільність slug:
product-URL і людино-зчитувані slug-и можуть дрейфувати. Пом’якшення: внутрішньо надавати пріоритет первинним ID, а slug тримати як вторинний ключ. Дрейф семантичних полів:
/ outcomesінтерпретація може зламатися, якщо припущення про порядок схеми неправильні. Пом’якшення: перевіряти вирівнювання масивів та контрольні перевірки довжини на етапі інгесту.outcomePrices Тимчасова недоступність API або throttling:
публічні ендпоінти можуть падати або повертати часткові payload-и. Пом’якшення: повторні спроби з exponential backoff, poison-queue на повторних збоях і збереження попередніх знімків. Пізнє врегулювання та застарілі наративи:
статті з перевіркою можуть виходити до того, як settlement остаточно закриється. Пом’якшення: зберігати статус settlement як частину стану публікації та оновлювати пост-хок через незмінний журнал виправлень. З урахуванням стратегії trust-first для Naly пайплайн має бути налаштований як fail closed: краще затримати публікацію статті, ніж випускати її з неперевіреним станом ринку.

Нотатки з реалізації

За оголошеного runtime-стеку практична реалізація залишається прямолінійною:

Використовуйте server handlers Next.js (

) для розміщення ендпоінтів інгесту та запланованих завдань.next@16.0.7Зберігати нормалізовані рядки в Neon, використовуючи
через drizzle-orm@^0.44.7 з явними унікальними обмеженнями на ідентифікатори ринку. @neondatabase/serverless@^1.0.2 Зберігати сирі payload-знімки у Vercel Blob (
) для аудиту й постфактум-порівнянь.@vercel/blob@^2.0.0Тримати генерацію markdown-джерела та збирання статей поза ядром інгесту; використовувати
для безпечного перетворення та marked@^17.0.1 плюс ai@6.0.0-beta.105 лише після проходження перевірок цілісності даних. @anthropic-ai/claude-agent-sdk@^0.2.15 Використовуйте
/ tsx@^4.21.0для відтворюваних одноразових повторів під час backfilling історичних вікон.typescript@^5.9.3 Станом на 10 червня 2026 року архітектура має пріоритизувати три суворі результати: незмінність сирих знімків, детерміноване проєкціювання в внутрішню схему та аудит-лінію, орієнтовану на верифікацію, від URL-джерела API до фінального посилання у статті.

Джерела