Інженерні нотатки Naly: Polymarket Gamma як відтворюваний шар ринкових знімків

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

Анотація

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

Теза цієї нотатки полягає в тому, що Naly має інжестувати Gamma у версіонований шар ринкових знімків. Знімок — це не істина; це спостережений публічний стан ринку в конкретний момент часу, прив’язаний до URL джерел і збережених сирих payloads. Це дозволяє Naly публікувати те, що інші приховують: ринковий контекст, межі сигналу й точні докази, використані під час генерації статті.

Де це розташовано в Naly

Інжестія Gamma розташована перед генерацією статті й після виявлення зовнішніх джерел. У видавничому шляху Naly вона забезпечує сторону ринку прогнозів у пакеті доказів для чотирьох подальших застосувань:

Оглядам неправильного ціноутворення потрібні поточні кандидати подій і ринків із достатньою кількістю метаданих, щоб порівнювати ринково-імпліковані ймовірності з міркуваннями, підкріпленими джерелами.
Статтям із прогнозами KBO потрібні спортивні ринки, теги команд або подій, дедлайни подій і мітки результатів, які можна відрендерити без ручного введення ринкового контексту.
Цитуванням джерел потрібні стабільні URL ринків, слаги подій та ідентифікатори ринків, щоб читач міг перевірити, чому стаття обговорювала конкретний контракт.
Верифікації прогнозів потрібні історичні знімки, щоб пізнішу резолюцію можна було оцінити проти ймовірності, яку Naly фактично бачив на момент публікації.

Локальні факти runtime важливі переважно для форми, а не для новизни. 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 підтримує як endpoints зі стилем offset, так і endpoints keyset. Для великих або повторюваних обходів keyset-пагінація безпечніша, бо next_cursor стає токеном продовження, а offset явно відхиляється на keyset markets endpoint. Для менших таргетованих завдань статей offset-пагінація все ще може бути прийнятною, коли вікно запиту вузьке, а вихід негайно знімається у snapshot.
Нормалізація. Ключове правило нормалізації полягає в тому, що мітки результатів і ціни результатів мають зіставлятися за позицією. Огляд ринкових даних Polymarket документує outcomes і outcomePrices масиви як взаємно однозначні масиви, тому дисципліна індексів має значення. Переплутаний масив — це не косметична помилка; він перевертає ринкову інтерпретацію статті.
Створення знімків. Зберігайте і нормалізовані колонки, і сирий JSON. Нормалізовані колонки мають включати провайдера, часову мітку отримання, id або slug події, id або slug ринку, текст запитання, condition id за наявності, token identifiers за наявності, мітки результатів, ціни результатів, прапорці active і closed, end time, tags, source URL і payload hash. Сирий JSON захищає Naly від дрейфу схеми й дозволяє верифікації відтворити точний артефакт інжестії.
Оцінювання кандидатів. Завдання статей мають ранжувати ринки за редакційними критеріями, а не критеріями торгового виконання: свіжість, обсяг або ліквідність, де доступно, близькість резолюції, доступність джерел, відповідність категорії та чи може ринок створити чіткий контраст для читача. Оцінювання кандидатів ніколи не має натякати, що ринкова ціна автоматично неправильна; воно має позначати ринок як вартий дослідження.
Прив’язка публікації. Коли згенерована стаття цитує ринок, стаття має посилатися на збережений snapshot id, source URL Polymarket і набір зовнішніх доказів, використаний автором. Це різниця між сторінкою, яка каже, що ринок був 62 percent, і сторінкою, яка може довести коли, де й з якого payload походило це значення.

Rate limits є частиною механізму. Polymarket документує throttling, який застосовується Cloudflare, і конкретні ліміти Gamma для /events, /markets, /tags, і /public-search. Naly не потрібно наближатися до цих лімітів для щоденної публікації, тому правильна позиція консервативна: обмежена конкурентність, повтор із jitter, payload hashes для ідемпотентності та alerting, коли завдання отримує throttled, empty або структурно неочікувані responses.

Що каже література

Нещодавні роботи arXiv підтримують дизайн snapshot-first. Jia et al. описують дані децентралізованих ринків прогнозів як фрагментовані між off-chain метаданими, торговими записами на рівні fill і подіями oracle-resolution, а потім обґрунтовують уніфіковану реляційну систему з розв’язанням ідентифікаторів, інкрементальними оновленнями та механізмами узгодженості. Менша видавнича система Naly має той самий клас проблеми: самих ринкових метаданих недостатньо, якщо їх пізніше не можна поєднати з цінами, твердженнями статей і результатами резолюції.

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

Робота Dubach про мікроструктуру Polymarket здебільшого стосується даних книги заявок, але дає корисне попередження для дизайну інжестії: високочастотні ринкові докази мають специфічні для джерела режими помилок, затримки інжестії та join-и, які мають значення. Gamma менш гранулярний, ніж фіди книги заявок, але той самий принцип застосовується. Джерело числа має бути видимим. Знімок Gamma, CLOB midpoint і on-chain запис угоди пов’язані, але не взаємозамінні.

Madrigal-Cianci, Monsalve Maya і Breakey формулюють ринки прогнозів як байєсівські обернені задачі, де спостережені історії ймовірностей і обсягів є шумними, ендогенними та сформованими неоднорідними типами трейдерів. Це підсилює редакційну позицію Naly. Інжестований стан ринку — це доказ, а не вердикт. Добра інженерія робить цю невизначеність доступною для перевірки замість того, щоб згладжувати її під час генерації.

Проєктні компроміси

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

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

Сирий JSON проти типізованої схеми — третій компроміс. Лише сирий JSON легко зберігати, але важко безпечно запитувати. Лише типізовані колонки легко запитувати, але вони крихкі, коли поля провайдера еволюціонують. Стійкий патерн — обидва: типізовані поля для ранжування, рендерингу та join-ів; сирі payloads для аудиту, replay і міграції.

Live render проти frozen render — четвертий компроміс. Live market widget може бути корисним, але твердження статті мають прив’язуватися до знімка на момент публікації. Інакше стара стаття може тихо змінити значення, коли Polymarket зсуває, закриває або резолвить ринок. Для стратегії довіри Naly frozen evidence важливіші за свіжість, коли сторінка робить датоване твердження.

Режими відмов

Найнебезпечніша відмова — неузгодженість outcome-price. Якщо Yes і No мітки парсяться окремо від цін, стаття може інвертувати сигнал, залишаючись правдоподібною на вигляд.

Друга відмова — повторне використання застарілого ринку. Ринок може бути активним під час виявлення і закритим на момент публікації. Кожне завдання статті має повторно валідовувати поля active, closed, archived і end-time безпосередньо перед прив’язкою знімка.

Третя відмова — неоднозначність багатьох ринків. Подія Polymarket може містити кілька торгованих ринків. Огляд може цитувати подію, але запис верифікації має цитувати конкретний ринок і результат, які оцінював Naly.

Четверта відмова — дрейф схеми. Публічні APIs змінюють назви полів, дефолти та вкладені зв’язки. Сховище знімків має включати payload hashes, parser version, provider URL і validation errors, щоб дрейф був спостережуваним.

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

Шоста відмова — втрата цитування. Якщо стаття зберігає лише відрендерений markdown, подальша верифікація не може довести, яка сторінка ринку і payload підтримували твердження. Article-market joins мають бути першокласними записами, а не вбудованою прозою.

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

Практична реалізація Naly може тримати контракт інжестії невеликим:

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

Генератор статей має отримувати це як структуровані докази, а не як вільний prompt text. Потім він може створити markdown через наявний AI stack, відрендерити через site pipeline і зберегти цитування прикріпленими до source records. Працівник верифікації згодом може поєднати ринковий знімок статті з даними резолюції й оцінити, чи добре постаріло опубліковане твердження.

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