Naly Engineering Notizen: Polymarket-Gamma-API-Ingestion für Vorhersagemarkt-Artikel

TL;DRNaly nutzt die Gamma-API von Polymarket als deterministische Discovery- und Pricing-Basis für alle Vorhersagemarkt-Workflows, wodurch ad-hoc-Nachrichtenscrapes durch strukturierte Marktentitäten ersetzt werden. In jedem Zyklus wandelt es Live-Ereignisse und -Märkte in artikelfähige Signale für Fehlpreisungs-Rundowns, KBO-Vorschauen, Zitationspakete und spätere Ergebnisverifikation um, sodass die Story-Generierung immer auf öffentlich beobachtbaren Wahrscheinlichkeiten und Marktstruktur basiert statt auf abgeleiteten Meinungen.

Abstract

Naly nutzt Vorhersagemarkt-Daten als Infrastruktur, nicht als Aufsatz, damit redaktionelle Produkte direkt an einem externen Marktzustand hängen, der später auditierbar ist. Die Gamma-API stellt ohne Wallet-Keys einen Lesepfad für Ereignisse, Märkte, Tags und Preise bereit. Die zentrale Designherausforderung ist es, diese Ingest-Schicht stabil genug für Zuverlässigkeit zu halten und dennoch flexibel genug für Content-Teams, die eine schnelle Themenentdeckung brauchen.

Position in Naly

Die Polymarket-Gamma-Ingestion liegt an der vorgelagerten Grenze zwischen rohen Marktgrundlagen und veröffentlichungsfertigen redaktionellen Assets. Sie ist der erste Schritt einer größeren Pipeline:

Eingabeschicht: Events, Märkte, Tags und Marktstatus aus Gamma abrufen.
Interpretationsschicht: in Naly's internes Schema normalisieren (event_id, market_id, Token-IDs, Outcomes, Wahrscheinlichkeiten, Zeitstempel, aktive/geschlossene Flags).
Narrativschicht: normalisierte Inputs für Fehlpreisungs-Rundowns und KBO-Vorhersage-Entwurfsströme bereitstellen.
Validierungsschicht: aufgelöste/geschlossene Marktzustände vorhalten für spätere Wahrheitsprüfung von Artikeln und retrospektive Scorecards.

Stand 10. Juni 2026 ist dies besonders abgestimmt auf aktive Taktiken, die vertrauenswürdige, zitationsreife Prognosebelege benötigen: Kalibrierungs-Transparenz der Vorhersagen, wiederholbare Content-Beschaffung und spätere Verifizierungs-Workflows.

Technischer Mechanismus

Polymarket definiert drei APIs, wobei Gamma als öffentliche Discovery-Ebene für Ereignis-/Marktübersicht und Metadaten dient, während das Orderbuch-/Handelsdaten über CLOB und Benutzerdaten/Positionen über die Data API (Dokumente). Gamma und Data sind laut Polymarket-Dokumenten öffentlich, während CLOB private/trading-Interfaces besitzt, die für Order-Operationen Authentifizierung erfordern.

Naly kann mit nur öffentlichen Endpunkten einen robusten täglichen Ablauf umsetzen:

Aktive Kandidatenmärkte entdecken über GET /events mit active=true, closed=falsePaginierung (limit, offset), und optionale Sortierfilter.
Auf zugehörige Einzelmärkte ausweiten mittels Ereignis-Payloads, da Ereignisse zugehörige Märkte enthalten und im Vergleich zu einzelnen Marktabfragen weniger API-Aufrufe erfordern.
Exakte Entitäten ansteuern mit Slug-basierten Aufrufen, wenn ein bekanntes Ereignis oder Markt bereits identifiziert wurde.
Preise normalisieren durch Zuordnung outcomes und outcomePrices Index-für-Index-Zuordnung in benannte Wahrscheinlichkeiten.
Audit-Artefakte speichern sowohl als normalisierte Zeilen als auch als Roh-Snapshots, sodass jeder Artikel jede herangezogene Kennzahl zurückverfolgen kann.
Nachgelagerte Generierung steuern über Frische- und Schemata-Prüfungen; veraltete oder unvollständige Snapshots werden vor der Nutzung zur Aktualisierung markiert.

Die Gamma-Dokumentation beschreibt genau diese betriebliche Struktur: öffentliche Endpunkte wie /events, /markets, /public-search, /tags, und /series stehen für Discovery zur Verfügung, während Pagination und Filterung über limit/offset, tag_id, sowie verwandte Filter unterstützt werden. Sie gibt außerdem direkte Empfehlungen für drei Abrufmuster: Slug-Lookup, tag-basierte Discovery und Ereignisaufzählung für breite Scans. Für Naly ist das Event-First-Muster beim Aufbau vieler täglicher Kandidaten am kosten-effizientesten, weil jedes Ereignis viele Marktdatensätze bereitstellen kann.

In der Praxis sollte ein minimaler Source-of-Truth-Datensatz für Naly Folgendes enthalten:

Ereignis- und Markt-IDs
Markt question
clobTokenIds (für nachgelagerte Preisangleichung mit CLOB, falls erforderlich)
outcomes und outcomePrices
enableOrderBook
active, closedsowie Zeitfelder (Start-/Endzeitstempel)
Abrufzeitstempel und Quellen-URL

Obwohl Gamma bereits eine starke probabilistische Basis liefern kann, ist ein zweiter Verfeinerungspfad optional: wenn Naly kürzere Intraday-Updates braucht, können CLOB-Endpunkte wie /price, /prices, oder /book später zusammengeführt werden.

Was die Literatur sagt

Die Forschung zu Vorhersagemärkten stützt diesen Daten-First-Ansatz, fügt jedoch Absicherungen bei der Interpretation hinzu.

Das Marktdatenmodell in Vorhersagemärkten ist nur nützlich, wenn es kalibriert und korrekt interpretiert wird; Preise sind ohne Kontext keine universellen Wahrscheinlichkeiten. Eine Studie aus dem Jahr 2026 zu Polymarket und Kalshi fand systematische Kalibrierungsmuster, die je nach Domäne und Zeithorizont variieren, einschließlich messbarer Unterkonfidenz in bestimmten Bereichen.
Eine weitere, 2026 veröffentlichte, lebenszyklusorientierte Studie betont, dass eine sinnvolle Marktanalyse eine synchronisierte Datenverarbeitung über mehrere Ebenen erfordert: Marktmetadaten, Handelsereignisse und Auflösungssignale müssen explizit verknüpft und regelmäßig auf Konsistenz geprüft werden, statt isolierte Abrufe zu verwenden.
Frühere Arbeiten zur Markt-Mikrostruktur zeigen, dass Marktpreise im kontinuierlichen Auktionsstil Informationsfluss von Tradern transportieren. Deshalb kann Naly Marktpreise als kollektive-Vorhersage-Signale behandeln und dennoch Ergebnisse über die Zeit validieren.
Die Prognoseforschung, die Marktpreise mit anderen Methoden vergleicht (etwa survey-basierte Prognosen), zeigt, dass Vorhersagemärkte sehr prädiktiv sein können, jedoch nur, wenn die Ergebnisverifikation und Modelldisziplin gewahrt bleiben.

Die praktische Folge für Naly ist eindeutig: alles mit Herkunft erfassen, niemals einen einzelnen Preis-Snapshot als endgültige Wahrheit behandeln und readiness (Datenaktualität + Integrität) von story quality (redaktioneller Einordnung) trennen.

Design-Abwägungen

Naly optimiert die Ingestion bewusst auf Zuverlässigkeit statt auf Geschwindigkeit.

Nur Gamma vs. Gamma+CLOB: Gamma liefert stabile Discovery- und öffentliche Kontextdaten schnell; die Ergänzung durch CLOB verbessert die Microstructure-Reichweite, bringt aber Auth- und Endpunkt-Komplexität.
Täglicher Snapshot vs. kontinuierliches Streaming: Ein deterministischer geplanter Pull ist einfacher zu auditieren und reproduzieren als kontinuierliche Streams, verpasst jedoch Umbrüche im Unter-Minuten-Bereich.
Event-first-Pull vs. market-first-Pull: Event-first reduziert doppelte Aufrufe und verbessert die Kontextabdeckung; market-first liefert bei engen Aufgaben eine geringfügig kleinere Payload-Größe.
Breites Schema vs. striktes Schema: Ein breites JSON-First-Schema beschleunigt die Integration, erhöht aber das Risiko von Schema-Drift; strenge Normalisierung erkennt Drift früher, verursacht aber mehr Migrationsaufwand.
Generische Felder vs domänenspezifische Felder: Gemeinsam genutzte Felder verbessern die Wiederverwendung über Artikel hinweg; domänenspezifische Erweiterungen (z. B. sportspezifische Vertrauensfenster) erhöhen die Präzision sofort, können aber langfristige Wartung fragmentieren.

Angesichts des Ziels von Naly für Nutzervertrauen und -bindung sollten strenge Reproduzierbarkeit und Zitierqualität die unmittelbare Latenzoptimierung überwiegen.

Ausfallmodi

Die größten Ausfallmodi sind operativ, nicht algorithmisch.

Fehlende Daten wegen Pagination-Fehlern: wenn limit und offset Fenster zwischen Polling-Läufen wechseln, können Duplikate oder Lücken entstehen. Abhilfe: Pagination-Cursor checkpointen und idempotente Upserts erzwingen.
Default closed=false Verlust historischer Kontextinformationen: Open-Market-Pulls lassen aufgelöste Elemente weg, sofern closed=true nicht explizit abgefragt wird. Abhilfe: einen dedizierten historischen Backfill-Pfad für Verifizierungsaufgaben betreiben.
Slug-Instabilität: Produkt-URLs und menschenlesbare Slugs können driften. Abhilfe: intern primäre IDs bevorzugen und Slug als sekundären Schlüssel behalten.
Semantische Feld-Drift: outcomes/outcomePrices die Interpretation kann brechen, wenn Annahmen über die Reihenfolge im Schema falsch sind. Abhilfe: Array-Ausrichtung und Längenprüfungen beim Ingest erzwingen.
Vorübergehende API-Verfügbarkeit oder Drosselung: Öffentliche Endpunkte können ausfallen oder Teil-Payloads liefern. Abhilfe: erneute Versuche mit exponentiellem Backoff, Poison-Queue bei wiederholten Fehlern und Vorhalten vorheriger Snapshots.
Späte Auflösung und veraltete Narrative: Verifizierungsartikel können entstehen, bevor die Abrechnung sauber abgeschlossen ist. Abhilfe: Settlement-Status als Teil des Publish-Status speichern und im Nachhinein mit einem unveränderbaren Korrekturprotokoll aktualisieren.

Aufgrund der Trust-first-Strategie von Naly sollte die Pipeline Fail-Closed arbeiten: besser einen Artikel verzögern als ihn mit nicht verifizierbarem Marktzustand zu veröffentlichen.

Implementierungshinweise

Mit dem genannten Runtime-Stack bleibt die Umsetzung praktisch unkompliziert:

Nutze Next.js-Server-Handler (next@16.0.7), um Ingestion-Endpunkte und geplante Jobs zu hosten.
Persistiere normalisierte Zeilen in Neon mit drizzle-orm@^0.44.7 über @neondatabase/serverless@^1.0.2 mit expliziten Unique-Constraints auf Marktkennungen.
Speichere Roh-Payload-Snapshots in Vercel Blob (@vercel/blob@^2.0.0), für Auditierbarkeit und Post-Mortem-Diffing.
Halte Markdown-Quelltext-Generierung und Artikelerstellung außerhalb des Ingestion-Kerns; nutze marked@^17.0.1 für sichere Transformationen und ai@6.0.0-beta.105 sowie @anthropic-ai/claude-agent-sdk@^0.2.15 nur nach erfolgreicher Datenintegritätsprüfung.
Nutze tsx@^4.21.0/typescript@^5.9.3 für reproduzierbare Einzel-Neuverarbeitung, wenn historische Fenster nachgefüllt werden.

Am 10. Juni 2026 sollte die Architektur drei harte Ergebnisse priorisieren: Unveränderlichkeit roher Snapshots, deterministische Projektion in das interne Schema und eine verifizierungsorientierte Auditspur von der Quell-API-URL bis zur finalen Artikelzitierung.