Notatki inżynieryjne Naly: Polymarket Gamma jako odtwarzalna warstwa migawek rynku

TL;DRIngestia Polymarket Gamma daje Naly publiczny, ustrukturyzowany widok zdarzeń, rynków, wyników, cen, tagów i metadanych rozstrzygnięć z rynków predykcyjnych. Naly używa tej warstwy do wybierania kandydatów na artykuły, zakotwiczania przeglądów błędnych wycen, wspierania tekstów predykcyjnych o KBO, zachowywania cytowań źródeł i tworzenia trwałych migawek rynku do późniejszej weryfikacji. Teza inżynieryjna jest prosta: zaufanie redakcyjne zaczyna się od odtwarzalnych danych wejściowych z rynku, a nie od wygenerowanej prozy.

Streszczenie

Polymarket Gamma API należy traktować jako źródło odkrywania rynków i metadanych dla Naly, a nie jako interfejs tradingowy. Oficjalna dokumentacja Polymarket oddziela Gamma od API Data i CLOB: Gamma obejmuje zdarzenia, rynki, tagi, serie, metadane sportowe, wyszukiwanie, komentarze i profile publiczne, podczas gdy CLOB obsługuje arkusze zleceń, ceny, spready i uwierzytelnione operacje tradingowe. Dla artykułów Naly ta granica jest użyteczna. Większość przepływów redakcyjnych potrzebuje treści pytania, tożsamości rynku, etykiet wyników, wyświetlanych prawdopodobieństw, tagów kategorii, terminów i kontekstu rozstrzygnięcia wcześniej niż szczegółów arkusza zleceń na poziomie ticków.

Teza tej notatki jest taka, że Naly powinno ingestować Gamma do wersjonowanej warstwy migawek rynku. Migawka nie jest prawdą; jest zaobserwowanym publicznym stanem rynku w konkretnym czasie, powiązanym z URL-ami źródeł i zachowanymi surowymi ładunkami danych. To pozwala Naly publikować to, co inni ukrywają: kontekst rynku, ograniczenia sygnału i dokładne dowody użyte podczas generowania artykułu.

Gdzie mieści się w Naly

Ingestia Gamma znajduje się przed generowaniem artykułu i po odkrywaniu zewnętrznych źródeł. W ścieżce publikacyjnej Naly dostarcza część pakietu dowodowego dotyczącą rynku predykcyjnego dla czterech dalszych zastosowań:

Przeglądy błędnych wycen potrzebują aktualnych kandydatów zdarzeń i rynków, z metadanymi wystarczającymi do porównania prawdopodobieństw implikowanych przez rynek z rozumowaniem opartym na źródłach.
Artykuły predykcyjne o KBO potrzebują rynków sportowych, tagów drużyn lub zdarzeń, terminów zdarzeń i etykiet wyników, które można wyrenderować bez ręcznie wprowadzanego kontekstu rynku.
Cytowania źródeł potrzebują stabilnych URL-i rynków, slugów zdarzeń i identyfikatorów rynków, aby czytelnik mógł sprawdzić, dlaczego artykuł omawiał konkretny kontrakt.
Weryfikacja predykcji potrzebuje historycznych migawek, aby późniejsze rozstrzygnięcie można było ocenić względem prawdopodobieństwa, które Naly faktycznie widziało w momencie publikacji.

Lokalne fakty runtime mają znaczenie głównie dla kształtu, nie dla nowości. TypeScript 5.9 i tsx są rozsądnym wyborem dla skryptów ingestii; drizzle-orm z @neondatabase/serverless może utrwalać znormalizowane rekordy i surowy JSON; Next.js 16 i React 19 mogą renderować wynikowe strony artykułów; pakiety ai i Claude SDK mogą konsumować przygotowany pakiet dowodowy dopiero po tym, jak ingestia uczyni stan rynku jawny.

Mechanizm techniczny

Solidna pętla ingestii Gamma ma sześć etapów.

Odkrywanie. Używaj zdarzeń Gamma, gdy Naly potrzebuje szerokiego odkrywania aktywnych rynków, oraz slugów rynku lub zdarzenia, gdy artykuł jest zakotwiczony w znanym URL-u Polymarket. Przewodnik Polymarket po danych rynkowych zaleca zdarzenia do pełnego aktywnego odkrywania, ponieważ zdarzenia zawierają powiązane rynki, zmniejszając liczbę wywołań API. W przypadku pracy kategorialnej, takiej jak sport, tagi i metadane sportowe powinny zawężać crawl przed rankingowaniem kandydatów.
Paginacja. Gamma obsługuje zarówno endpointy w stylu offset, jak i endpointy keyset. Dla dużego lub powtarzanego crawlowania paginacja keyset jest bezpieczniejsza, ponieważ next_cursor staje się tokenem kontynuacji, a offset jest wyraźnie odrzucane na endpoincie rynków keyset. Dla mniejszych, ukierunkowanych zadań artykułowych paginacja offset może nadal być akceptowalna, gdy okno zapytania jest wąskie, a wynik jest natychmiast zapisywany jako migawka.
Normalizacja. Kluczowa zasada normalizacji jest taka, że etykiety wyników i ceny wyników muszą być mapowane według pozycji. Przegląd danych rynkowych Polymarket dokumentuje outcomes i outcomePrices jako tablice jeden do jednego, więc dyscyplina indeksów ma znaczenie. Zamieniona tablica nie jest kosmetycznym błędem; odwraca interpretację rynku w artykule.
Migawkowanie. Przechowuj zarówno znormalizowane kolumny, jak i surowy JSON. Znormalizowane kolumny powinny obejmować dostawcę, znacznik czasu pobrania, id lub slug zdarzenia, id lub slug rynku, treść pytania, condition id, gdy występuje, identyfikatory tokenów, gdy występują, etykiety wyników, ceny wyników, flagi active i closed, czas zakończenia, tagi, URL źródłowy i hash ładunku danych. Surowy JSON chroni Naly przed dryfem schematu i pozwala weryfikacji odtworzyć dokładny artefakt ingestii.
Punktacja kandydatów. Zadania artykułowe powinny rankingować rynki według kryteriów redakcyjnych, a nie kryteriów realizacji transakcji: świeżości, wolumenu lub płynności tam, gdzie są dostępne, bliskości rozstrzygnięcia, dostępności źródeł, dopasowania kategorii oraz tego, czy rynek może wytworzyć wyraźny kontrast dla czytelnika. Punktacja kandydatów nigdy nie powinna sugerować, że cena rynkowa jest automatycznie błędna; powinna oznaczać rynek jako wart zbadania.
Powiązanie publikacyjne. Gdy wygenerowany artykuł cytuje rynek, artykuł powinien linkować do zapisanego id migawki, źródłowego URL-u Polymarket i zestawu zewnętrznych dowodów użytego przez autora. To różnica między stroną, która mówi, że rynek wynosił 62 procent, a stroną, która potrafi udowodnić, kiedy, gdzie i z jakiego ładunku danych ta wartość pochodziła.

Limity szybkości są częścią mechanizmu. Polymarket dokumentuje throttling wymuszany przez Cloudflare oraz konkretne limity Gamma dla /events, /markets, /tags, i /public-search. Naly nie musi zbliżać się do tych limitów przy codziennym publikowaniu, więc właściwa postawa jest konserwatywna: ograniczona współbieżność, ponawianie z jitterem, hashe ładunków danych dla idempotencji oraz alertowanie, gdy zadanie otrzymuje odpowiedzi throttled, puste lub strukturalnie nieoczekiwane.

Co mówi literatura

Najnowsze prace z arXiv wspierają projektowanie typu snapshot-first. Jia et al. opisują dane zdecentralizowanych rynków predykcyjnych jako rozproszone między metadanymi off-chain, rekordami tradingowymi na poziomie wypełnień i zdarzeniami rozstrzygnięć oracle, a następnie argumentują za ujednoliconym systemem relacyjnym z rozwiązywaniem identyfikatorów, aktualizacjami przyrostowymi i mechanizmami spójności. Mniejszy system publikacyjny Naly ma problem tej samej klasy: same metadane rynku nie wystarczą, jeśli później nie można ich połączyć z cenami, twierdzeniami artykułów i wynikami rozstrzygnięć.

Badanie kalibracji Le jest bezpośrednio istotne dla języka artykułów. Korzystając z dużych zbiorów danych Kalshi i Polymarket, artykuł argumentuje, że kalibracja zależy od domeny, horyzontu i efektów wielkości transakcji; konsumenci, którzy traktują ceny jako prawdopodobieństwa wprost, mogą systematycznie je błędnie interpretować. Dla Naly oznacza to, że artykuł powinien mówić o prawdopodobieństwie implikowanym przez rynek, zaobserwowanej cenie lub publicznym sygnale rynkowym, a nie o prawdzie. Artykuł może omawiać możliwą błędną wycenę dopiero po oddzieleniu surowej obserwacji rynkowej od modelu Naly lub rozumowania opartego na źródłach.

Artykuł Dubacha o mikrostrukturze Polymarket dotyczy głównie danych arkusza zleceń, ale daje użyteczne ostrzeżenie dla projektu ingestii: dowody rynkowe o wysokiej częstotliwości mają specyficzne dla źródła tryby błędów, opóźnienia ingestii i złączenia, które mają znaczenie. Gamma jest mniej granularna niż feedy arkusza zleceń, jednak obowiązuje ta sama zasada. Źródło liczby musi być widoczne. Migawka Gamma, midpoint CLOB i rekord transakcji on-chain są powiązane, ale nie są zamienne.

Madrigal-Cianci, Monsalve Maya i Breakey ujmują rynki predykcyjne jako bayesowskie problemy odwrotne, w których obserwowane historie prawdopodobieństw i wolumenów są zaszumione, endogeniczne i kształtowane przez heterogeniczne typy traderów. To wzmacnia postawę redakcyjną Naly. Ingestowany stan rynku jest dowodem, nie wyrokiem. Dobra inżynieria sprawia, że tę niepewność można inspectować, zamiast wygładzać ją podczas generowania.

Kompromisy projektowe

Gamma kontra CLOB to pierwszy kompromis. Gamma daje Naly odkrywalność, kontekst artykułów i metadane. CLOB daje ostrzejszą wycenę i mechanikę arkusza zleceń. Dla codziennych artykułów inżynieryjnych i przeglądów rynków predykcyjnych Gamma powinna być domyślnym wejściem, ponieważ odpowiada na pytanie, czego dotyczy rynek. CLOB można dodać, gdy artykuł potrzebuje spreadu, midpointu lub precyzji historii cen.

Ingestia event-first kontra market-first to drugi kompromis. Event-first jest tańsze dla szerokich skanów, ponieważ zdarzenie może zawierać wiele rynków i współdzielone metadane. Market-first jest czystsze dla weryfikacji, ponieważ ostateczna ocena przypina się do konkretnego wyniku binarnego. Naly powinno ingestować oba kształty, ale sprawiać, by linki w artykułach wskazywały na twierdzenie na poziomie rynku zawsze wtedy, gdy oceniany jest pojedynczy wynik.

Surowy JSON kontra typowany schemat to trzeci kompromis. Sam surowy JSON łatwo przechowywać, ale trudno bezpiecznie odpytywać. Same typowane kolumny łatwo odpytywać, ale są kruche, gdy pola dostawcy ewoluują. Trwały wzorzec to oba rozwiązania: typowane pola do rankingowania, renderowania i złączeń; surowe ładunki danych do audytu, odtwarzania i migracji.

Renderowanie na żywo kontra zamrożone renderowanie to czwarty kompromis. Widget rynku na żywo może być użyteczny, ale twierdzenia w artykułach muszą wiązać się z migawką z czasu publikacji. W przeciwnym razie stary artykuł może po cichu zmienić znaczenie, gdy Polymarket przesunie, zamknie lub rozstrzygnie rynek. Dla strategii zaufania Naly zamrożone dowody są lepsze niż świeżość, gdy strona formułuje twierdzenie datowane.

Tryby awarii

Najbardziej niebezpieczną awarią jest niedopasowanie wyniku do ceny. Jeśli etykiety Yes i No są parsowane oddzielnie od cen, artykuł może odwrócić sygnał, nadal wyglądając wiarygodnie.

Drugą awarią jest ponowne użycie nieaktualnego rynku. Rynek może być aktywny podczas odkrywania i zamknięty w momencie publikacji. Każde zadanie artykułowe powinno ponownie zweryfikować pola active, closed, archived i end-time bezpośrednio przed powiązaniem migawki.

Trzecią awarią jest niejednoznaczność wielu rynków. Zdarzenie Polymarket może zawierać kilka rynków zdatnych do handlu. Przegląd może cytować zdarzenie, ale rekord weryfikacyjny musi cytować konkretny rynek i wynik, który Naly oceniło.

Czwartą awarią jest dryf schematu. Publiczne API zmieniają nazwy pól, wartości domyślne i relacje zagnieżdżone. Przechowywanie migawek powinno obejmować hashe ładunków danych, wersję parsera, URL dostawcy i błędy walidacji, aby dryf był obserwowalny.

Piątą awarią jest przesadne twierdzenie o kalibracji. Cena rynkowa jest użytecznym sygnałem publicznym, ale literatura ostrzega przed traktowaniem jej jako czystego prawdopodobieństwa we wszystkich domenach i horyzontach. Copy Naly powinno zachowywać różnicę między prawdopodobieństwem implikowanym przez rynek, estymacją Naly i zrealizowanym wynikiem.

Szóstą awarią jest utrata cytowania. Jeśli artykuł przechowuje tylko wyrenderowany markdown, późniejsza weryfikacja nie może udowodnić, która strona rynku i który ładunek danych wspierały twierdzenie. Złączenia artykuł-rynek powinny być rekordami pierwszej klasy, a nie osadzone w prozie.

Uwagi implementacyjne

Praktyczna implementacja Naly może utrzymać mały kontrakt ingestii:

provider: polymarket-gamma.
provider_url: dokładny endpoint Gamma lub publiczny URL rynku użyty do odkrywania.
fetched_at: znacznik czasu serwera w UTC.
event_key i market_key: stabilne identyfikatory lub slugi dostawcy.
question: kanoniczna treść pytania rynkowego.
outcomes: uporządkowane etykiety.
outcome_prices: uporządkowane ciągi dziesiętne normalizowane do wartości liczbowych dopiero po walidacji.
status: flagi active, closed, archived i publishability.
raw_payload: pełna odpowiedź dostawcy.
payload_hash: deterministyczny hash dla idempotencji i odtwarzania.
parser_version: kontrakt kodu, który zinterpretował ładunek danych.

Generator artykułów powinien otrzymywać to jako ustrukturyzowane dowody, a nie jako luźny tekst promptu. Może następnie produkować markdown przez istniejący stos AI, renderować go za pomocą pipeline'u strony i utrzymywać cytowania przypięte do rekordów źródłowych. Worker weryfikacyjny może później połączyć migawkę rynku z artykułu z danymi rozstrzygnięcia i ocenić, czy opublikowane twierdzenie dobrze zniosło próbę czasu.

Zasada inżynieryjna jest celowo konserwatywna: ingestować, normalizować, zapisać migawkę, cytować, a potem pisać. Ta kolejność jest wolniejsza niż poproszenie modelu o przeglądnięcie i streszczenie strony rynku, ale tworzy artefakt, którego Naly naprawdę potrzebuje dla akwizycji i retencji: publiczny artykuł, którego dowody rynkowe można odtworzyć po poznaniu wyniku.