Naly Engineering Notes: Polymarket Gamma als reproduzierbare Markt-Snapshot-Schicht

TL;DRDie Polymarket-Gamma-Ingestion gibt Naly eine öffentliche, strukturierte Sicht auf Prognosemarkt-Events, Märkte, Ergebnisse, Preise, Tags und Auflösungsmetadaten. Naly nutzt diese Schicht, um Artikelkandidaten auszuwählen, Mispricing-Roundups zu verankern, KBO-Prognosegeschichten zu unterstützen, Quellenzitate zu bewahren und dauerhafte Markt-Snapshots für spätere Verifizierung zu erstellen. Die technische Aussage ist einfach: Redaktionelles Vertrauen beginnt mit reproduzierbaren Markteingaben, nicht mit generierter Prosa.

Zusammenfassung

Die Polymarket-Gamma-API sollte als Nalys Quelle für Marktentdeckung und Metadaten behandelt werden, nicht als Trading-Schnittstelle. Die offizielle Polymarket-Dokumentation trennt Gamma von Data- und CLOB-APIs: Gamma deckt Events, Märkte, Tags, Serien, Sportmetadaten, Suche, Kommentare und öffentliche Profile ab, während CLOB Orderbücher, Preise, Spreads und authentifizierte Trading-Operationen behandelt. Für Naly-Artikel ist diese Grenze nützlich. Die meisten redaktionellen Workflows benötigen Fragetext, Marktidentität, Ergebnislabels, angezeigte Wahrscheinlichkeiten, Kategorie-Tags, Fristen und Auflösungskontext, bevor sie tick-genaue Orderbuchdetails brauchen.

Die These dieser Notiz ist, dass Naly Gamma in eine versionierte Markt-Snapshot-Schicht aufnehmen sollte. Ein Snapshot ist nicht die Wahrheit; er ist der beobachtete öffentliche Marktzustand zu einem bestimmten Zeitpunkt, verbunden mit Quell-URLs und bewahrten Roh-Payloads. Das lässt Naly veröffentlichen, was andere verbergen: den Marktkontext, die Grenzen des Signals und die exakte Evidenz, die bei der Artikelerstellung verwendet wurde.

Wo es in Naly sitzt

Die Gamma-Ingestion sitzt vor der Artikelgenerierung und nach der Entdeckung externer Quellen. In Nalys Publishing-Pfad liefert sie die Prognosemarktseite des Evidenzbündels für vier nachgelagerte Nutzungen:

Mispricing-Roundups brauchen aktuelle Event- und Marktkandidaten mit genügend Metadaten, um marktimplizierte Wahrscheinlichkeiten mit quellenbasierter Begründung zu vergleichen.
KBO-Prognoseartikel brauchen Sportmärkte, Team- oder Event-Tags, Event-Fristen und Ergebnislabels, die ohne manuell eingegebenen Marktkontext gerendert werden können.
Quellenzitate brauchen stabile Markt-URLs, Event-Slugs und Marktkennungen, damit ein Leser prüfen kann, warum der Artikel einen bestimmten Kontrakt besprochen hat.
Prognoseverifizierung braucht historische Snapshots, damit die spätere Auflösung gegen die Wahrscheinlichkeit bewertet werden kann, die Naly zum Veröffentlichungszeitpunkt tatsächlich gesehen hat.

Die lokalen Laufzeitfakten sind vor allem für die Form relevant, nicht für die Neuheit. TypeScript 5.9 und tsx eignen sich gut für Ingestion-Skripte; drizzle-orm mit @neondatabase/serverless kann normalisierte Datensätze und Roh-JSON persistieren; Next.js 16 und React 19 können die resultierenden Artikelseiten rendern; die ai und Claude-SDK-Pakete können das vorbereitete Evidenzbündel erst konsumieren, nachdem die Ingestion den Marktzustand explizit gemacht hat.

Technischer Mechanismus

Eine robuste Gamma-Ingestion-Schleife hat sechs Stufen.

Entdeckung. Nutze Gamma-Events, wenn Naly eine breite Entdeckung aktiver Märkte braucht, und nutze Markt- oder Event-Slugs, wenn ein Artikel an eine bekannte Polymarket-URL gebunden ist. Polymarkets Leitfaden zu Marktdaten empfiehlt Events für vollständige aktive Entdeckung, weil Events zugehörige Märkte enthalten und API-Aufrufe reduzieren. Für Kategoriearbeit wie Sport sollten Tags und Sportmetadaten den Crawl eingrenzen, bevor Kandidaten gerankt werden.
Paginierung. Gamma unterstützt sowohl Offset-Endpunkte als auch Keyset-Endpunkte. Für große oder wiederholte Crawls ist Keyset-Paginierung sicherer, weil next_cursor zum Fortsetzungstoken wird und offset auf dem Keyset-Markets-Endpunkt ausdrücklich abgelehnt wird. Für kleinere gezielte Artikeljobs kann Offset-Paginierung weiterhin akzeptabel sein, wenn das Abfragefenster eng ist und die Ausgabe sofort als Snapshot gespeichert wird.
Normalisierung. Die zentrale Normalisierungsregel lautet, dass Ergebnislabels und Ergebnispresie positionsbasiert zugeordnet werden müssen. Polymarkets Marktdatenüberblick dokumentiert outcomes und outcomePrices Arrays als eins-zu-eins-Arrays, deshalb ist Indexdisziplin wichtig. Ein vertauschtes Array ist kein kosmetischer Fehler; es kehrt die Marktinterpretation des Artikels um.
Snapshotting. Speichere sowohl normalisierte Spalten als auch Roh-JSON. Normalisierte Spalten sollten Provider, Abrufzeitstempel, Event-ID oder -Slug, Markt-ID oder -Slug, Fragetext, Condition-ID sofern vorhanden, Token-Identifiers sofern vorhanden, Ergebnislabels, Ergebnispreise, Active- und Closed-Flags, Endzeit, Tags, Quell-URL und Payload-Hash enthalten. Roh-JSON schützt Naly vor Schema-Drift und lässt die Verifizierung das exakte Ingestion-Artefakt erneut abspielen.
Kandidatenbewertung. Artikeljobs sollten Märkte nach redaktionellen Kriterien ranken, nicht nach Ausführungskriterien für Trading: Aktualität, Volumen oder Liquidität, wo verfügbar, Nähe zur Auflösung, Quellenverfügbarkeit, Kategoriepassung und ob der Markt einen klaren leserorientierten Kontrast erzeugen kann. Kandidatenbewertung sollte niemals implizieren, dass ein Marktpreis automatisch falsch ist; sie sollte einen Markt als recherchierenswert markieren.
Publikationsbindung. Wenn ein generierter Artikel einen Markt zitiert, sollte der Artikel auf die gespeicherte Snapshot-ID, die Polymarket-Quell-URL und das vom Autor verwendete externe Evidenzset verlinken. Das ist der Unterschied zwischen einer Seite, die sagt, der Markt habe bei 62 Prozent gelegen, und einer Seite, die beweisen kann, wann, wo und aus welchem Payload dieser Wert kam.

Rate Limits sind Teil des Mechanismus. Polymarket dokumentiert Cloudflare-erzwungenes Throttling und spezifische Gamma-Limits für /events, /markets, /tags, und /public-search. Naly muss für tägliches Publishing nicht in die Nähe dieser Limits kommen, daher ist die richtige Haltung konservativ: begrenzte Parallelität, Retry mit Jitter, Payload-Hashes für Idempotenz und Alerting, wenn ein Job gedrosselte, leere oder strukturell unerwartete Antworten erhält.

Was die Literatur sagt

Aktuelle arXiv-Arbeiten stützen das Snapshot-first-Design. Jia et al. beschreiben Daten dezentraler Prognosemärkte als fragmentiert über Off-Chain-Metadaten, Trading-Datensätze auf Fill-Ebene und Oracle-Auflösungsereignisse und argumentieren dann für ein einheitliches relationales System mit Identifier-Auflösung, inkrementellen Updates und Konsistenzmechanismen. Nalys kleineres Publishing-System hat dieselbe Problemklasse: Marktmetadaten allein reichen nicht aus, sofern sie später nicht mit Preisen, Artikelaussagen und Auflösungsergebnissen verknüpft werden können.

Les Kalibrierungsstudie ist direkt relevant für Artikelsprache. Unter Verwendung großer Kalshi- und Polymarket-Datensätze argumentiert das Paper, dass Kalibrierung von Domain, Horizont und Trade-Size-Effekten abhängt; Konsumenten, die Preise als Wahrscheinlichkeiten zum Nennwert behandeln, können sie systematisch fehlinterpretieren. Für Naly bedeutet das, dass ein Artikel marktimplizierte Wahrscheinlichkeit, beobachteter Preis oder öffentliches Marktsignal sagen sollte, nicht Wahrheit. Der Artikel kann ein mögliches Mispricing erst besprechen, nachdem die rohe Marktbeobachtung von Nalys Modell oder quellenbasierter Begründung getrennt wurde.

Dubachs Polymarket-Mikrostruktur-Paper handelt vor allem von Orderbuchdaten, gibt aber eine nützliche Warnung für das Ingestion-Design: Hochfrequente Marktevidenz hat quellenspezifische Fehlermodi, Ingestion-Verzögerungen und Joins, die relevant sind. Gamma ist weniger granular als Orderbuch-Feeds, doch dasselbe Prinzip gilt. Die Quelle einer Zahl muss sichtbar sein. Ein Gamma-Snapshot, ein CLOB-Midpoint und ein On-Chain-Trade-Record sind verwandt, aber nicht austauschbar.

Madrigal-Cianci, Monsalve Maya und Breakey rahmen Prognosemärkte als bayessche inverse Probleme, bei denen beobachtete Wahrscheinlichkeits- und Volumenhistorien verrauscht, endogen und von heterogenen Trader-Typen geprägt sind. Das stärkt Nalys redaktionelle Haltung. Aufgenommener Marktzustand ist Evidenz, kein Urteil. Gute Technik macht diese Unsicherheit inspizierbar, statt sie während der Generierung auszuwaschen.

Design-Trade-offs

Gamma versus CLOB ist der erste Trade-off. Gamma gibt Naly Auffindbarkeit, Artikelkontext und Metadaten. CLOB gibt schärfere Preisbildung und Orderbuchmechanik. Für tägliche Engineering-Artikel und Prognosemarkt-Roundups sollte Gamma der Standardeingang sein, weil es beantwortet, worum es in dem Markt geht. CLOB kann ergänzt werden, wenn der Artikel Spread-, Midpoint- oder Preishistorienpräzision braucht.

Event-first versus Market-first-Ingestion ist der zweite Trade-off. Event-first ist günstiger für breite Scans, weil ein Event mehrere Märkte und gemeinsame Metadaten enthalten kann. Market-first ist sauberer für Verifizierung, weil der spätere Score an ein bestimmtes binäres Ergebnis gebunden ist. Naly sollte beide Formen ingestieren, aber Artikellinks auf die marktebene Aussage richten, wann immer ein einzelnes Ergebnis bewertet wird.

Roh-JSON versus typisiertes Schema ist der dritte Trade-off. Roh-JSON allein ist leicht zu speichern, aber schwer sicher abzufragen. Typisierte Spalten allein sind leicht abzufragen, aber brüchig, wenn Provider-Felder sich entwickeln. Das dauerhafte Muster ist beides: typisierte Felder für Ranking, Rendering und Joins; Roh-Payloads für Audit, Replay und Migration.

Live-Render versus eingefrorener Render ist der vierte Trade-off. Ein Live-Markt-Widget kann nützlich sein, aber Artikelaussagen müssen an den Snapshot zum Veröffentlichungszeitpunkt gebunden sein. Andernfalls kann ein alter Artikel stillschweigend seine Bedeutung ändern, wenn Polymarket einen Markt bewegt, schließt oder auflöst. Für Nalys Vertrauensstrategie schlägt eingefrorene Evidenz Aktualität, wenn eine Seite eine datierte Aussage macht.

Fehlermodi

Der gefährlichste Fehler ist die Fehlzuordnung von Ergebnis und Preis. Wenn Yes und No Labels getrennt von Preisen geparst werden, kann der Artikel das Signal invertieren und trotzdem plausibel aussehen.

Der zweite Fehler ist die Wiederverwendung veralteter Märkte. Ein Markt kann während der Entdeckung aktiv sein und zum Veröffentlichungszeitpunkt geschlossen sein. Jeder Artikeljob sollte active-, closed-, archived- und end-time-Felder unmittelbar vor der Bindung des Snapshots erneut validieren.

Der dritte Fehler ist Mehrmarkt-Mehrdeutigkeit. Ein Polymarket-Event kann mehrere handelbare Märkte enthalten. Ein Round-up kann das Event zitieren, aber ein Verifizierungsdatensatz muss den konkreten Markt und das Ergebnis zitieren, das Naly bewertet hat.

Der vierte Fehler ist Schema-Drift. Öffentliche APIs ändern Feldnamen, Defaults und verschachtelte Relationen. Snapshot-Speicherung sollte Payload-Hashes, Parser-Version, Provider-URL und Validierungsfehler enthalten, damit Drift beobachtbar ist.

Der fünfte Fehler ist überzogenes Kalibrierungsclaiming. Ein Marktpreis ist ein nützliches öffentliches Signal, aber die Literatur warnt davor, ihn über alle Domains und Horizonte hinweg als saubere Wahrscheinlichkeit zu behandeln. Nalys Text sollte den Unterschied zwischen marktimplizierter Wahrscheinlichkeit, Naly-Schätzung und realisiertem Ergebnis bewahren.

Der sechste Fehler ist Zitierverlust. Wenn ein Artikel nur gerendertes Markdown speichert, kann spätere Verifizierung nicht beweisen, welche Marktseite und welches Payload die Aussage gestützt haben. Artikel-Markt-Joins sollten First-Class-Records sein, nicht eingebettete Prosa.

Implementierungsnotizen

Eine praktische Naly-Implementierung kann den Ingestion-Vertrag klein halten:

provider: polymarket-gamma.
provider_url: der exakte Gamma-Endpunkt oder die öffentliche Markt-URL, die für die Entdeckung verwendet wurde.
fetched_at: Server-Zeitstempel in UTC.
event_key und market_key: stabile Provider-Identifiers oder Slugs.
question: kanonischer Fragetext des Marktes.
outcomes: geordnete Labels.
outcome_prices: geordnete Dezimalstrings, die erst nach Validierung zu numerischen Werten normalisiert werden.
status: Active-, Closed-, Archived- und Publishability-Flags.
raw_payload: vollständige Provider-Antwort.
payload_hash: deterministischer Hash für Idempotenz und Replay.
parser_version: der Codevertrag, der das Payload interpretiert hat.

Der Artikelgenerator sollte dies als strukturierte Evidenz erhalten, nicht als losen Prompt-Text. Er kann dann Markdown über den bestehenden AI-Stack erzeugen, mit der Site-Pipeline rendern und Zitate an Quelldatensätze gebunden halten. Ein Verifizierungsworker kann später den Markt-Snapshot des Artikels mit Auflösungsdaten verknüpfen und bewerten, ob die veröffentlichte Aussage gut gealtert ist.

Das Engineering-Prinzip ist bewusst konservativ: ingestieren, normalisieren, snapshotten, zitieren, dann schreiben. Diese Reihenfolge ist langsamer, als ein Modell zu bitten, eine Marktseite zu browsen und zusammenzufassen, aber sie erzeugt das Artefakt, das Naly für Akquise und Retention tatsächlich braucht: einen öffentlichen Artikel, dessen Marktevidenz nach Bekanntwerden des Ergebnisses erneut abgespielt werden kann.