Prognosemärkte gehören zu den technisch anspruchsvollsten Bereichen für die API-Entwicklung. Man hat es mit Finanzinstrumenten zu tun, die ablaufen, mit Wahrscheinlichkeiten, die sich in Echtzeit bepreisen, mit Ereignissen mit mehreren Ergebnissen und komplexen Kapitalbeziehungen sowie mit einer Nutzerbasis, die sowohl Menschen, die auf eine Benutzeroberfläche klicken, als auch automatisierte Handelsbots, die Arbitrage-Strategien ausführen, umfasst. Jede Designentscheidung wird sofort auf Herz und Nieren geprüft.
Polymarket, derzeit die weltweit größte Prognosemarkt-Plattform nach Volumen, hat aus genau diesem Grund ein API-Ökosystem aufgebaut, das es wert ist, studiert zu werden. Es ist nicht nur eine CRUD-API über einer Datenbank. Es ist eine sorgfältig geschichtete Architektur, die das grundlegende Spannungsverhältnis zwischen Offenheit und Sicherheit, zwischen Echtzeit- und historischen Daten sowie zwischen traditionellen Finanzmustern und krypto-nativen Primitiven bewältigt.
Hier sind acht Designmuster, die es wert sind, aus ihrer Vorgehensweise extrahiert zu werden.
Muster 1: Domänengetrennte API-Schichten
Polymarket stellt drei unterschiedliche APIs bereit, jede mit einer klaren Domäne:
- Gamma API (
gamma-api.polymarket.com) — Marktentdeckung, Ereignisse, Tags, Suche - CLOB API (
clob.polymarket.com) — Orderbuchdaten, Preisgestaltung, Orderplatzierung - Data API (
data-api.polymarket.com) — Benutzerpositionen, Trades, Analysen, Bestenlisten
Dies ist nicht nur eine Namenskonvention — jede API hat unterschiedliche Authentifizierungsanforderungen, unterschiedliche Update-Frequenzen und unterschiedliche Nutzerprofile. Die Gamma API ist vollständig öffentlich und für das Browsen und die Entdeckung optimiert. Die CLOB API hat sowohl öffentliche Endpunkte (jeder kann das Orderbuch lesen) als auch authentifizierte Endpunkte (Handel erfordert Anmeldeinformationen). Die Data API ist öffentlich, aber Wallet-adressiert — Sie fragen Positionen nach Benutzeradresse ab.
Die Designlektion hier ist, dass die Trennung nach Domäne statt nach Entität kohärentere APIs erzeugt. Ein naiver Ansatz würde Ihnen /markets, /orders, /users alle unter einem Dach bieten. Polymarket fragt stattdessen: „Wofür ist diese API gedacht?“ und baut dann um diese Frage herum auf. Entdeckung hat andere Zugriffsmuster als der Handel. Der Handel hat andere Latenzanforderungen als Analysen. Jedem eine eigene Basis-URL zu geben, bedeutet, dass sich jede unabhängig entwickeln, skalieren und authentifizieren kann.
Muster 2: Öffentlichkeitsorientierter Datenzugriff
Alles, was Marktdaten betrifft — Preise, Orderbücher, Ereignismetadaten, historische Trades — ist vollständig öffentlich:
curl "https://gamma-api.polymarket.com/events?limit=5"
Kein API-Schlüssel. Kein OAuth. Keine Ratenbegrenzungen (Rate Limits) auf Lese-Endpunkten. Sie erhalten die Daten.
Dies ist eine bewusste Entscheidung, die die meisten Finanzplattformen nicht treffen. Traditionelle Börsen hüten Marktdaten als Einnahmequelle. Polymarket behandelt sie als Infrastruktur – je mehr Menschen die Daten lesen und darauf aufbauen können, desto liquider und nützlicher wird der Markt. Es ist eine Logik der öffentlichen Güter, angewendet auf eine API.
Die praktische Konsequenz für API-Designer ist bemerkenswert: Die Trennung von Lese- und Schreibzugriff als erstklassige Sorge, anstatt die Authentifizierung einheitlich anzuwenden, ist fast immer die richtige Wahl für Plattformen, bei denen die Datenkonsumtion die Datenproduktion bei Weitem übersteigt. Wenn ein Benutzer Marktpreise ohne Anmeldeinformationen lesen kann, haben Sie die Reibung für 95 % Ihres potenziellen Publikums beseitigt. Reibung fügen Sie nur an der Stelle hinzu, wo es wirklich darauf ankommt – wenn sie eine echte Order platzieren möchten.
Muster 3: Zweistufige Authentifizierung, die echtes Vertrauen widerspiegelt
Handels-Endpunkte erfordern eine Authentifizierung, aber Polymarkets Authentifizierungsmodell hat eine Struktur, die die meisten API-Designer noch nicht gesehen haben: zwei Ebenen mit unterschiedlichen Zwecken.
L1 Authentifizierung verwendet eine EIP-712 Signatur vom privaten Schlüssel des Benutzers. Sie beweist den Besitz des Wallets. Sie verwenden sie genau einmal (oder selten), um API-Anmeldeinformationen abzuleiten:
// L1: Use your private key to derive API credentials
const credentials = await client.createOrDeriveApiKey();
// → { key: "...", secret: "...", passphrase: "..." }
L2 Authentifizierung verwendet HMAC-SHA256 mit diesen abgeleiteten Anmeldeinformationen. Sie ist das, was Sie an jede Handelsanfrage anhängen:
// L2 headers on every trading request
{
"POLY_ADDRESS": "0x...",
"POLY_SIGNATURE": "<hmac-sha256>",
"POLY_TIMESTAMP": "1716000000",
"POLY_API_KEY": "550e8400-...",
"POLY_PASSPHRASE": "..."
}
Die Erkenntnis ist, dass verschiedene Operationen unterschiedliche Sicherheitszeremonien verdienen. Das Erstellen von API-Schlüsseln erfordert den Nachweis der Kontrolle über das Wallet – das ist eine Aktion mit hohen Einsätzen, die eine kryptografische Signatur vom privaten Schlüssel verlangen sollte. Aber sobald dieses Vertrauen hergestellt ist, sollten routinemäßige Handelsanfragen kein erneutes Signieren mit dem privaten Schlüssel bei jedem Aufruf erfordern. L2-Anmeldeinformationen sind leichtgewichtig genug für den Hochfrequenzgebrauch, während sie weiterhin an die L1-Identität gebunden sind.
Dieses Muster reicht weit über Krypto hinaus: Stellen Sie es sich als den Unterschied zwischen „beweise, dass du diese Person bist“ (L1, selten mit dem stärksten verfügbaren Nachweis durchgeführt) und „beweise, dass diese Anfrage von dir kam“ (L2, ständig mit einem Sitzungsnachweis durchgeführt) vor. Die meisten Web-Anwendungen fassen diese in einem einzigen Authentifizierungsfluss zusammen und verlieren dabei die Sicherheitsnuance.
Muster 4: Orders als signierte Nachrichten, nicht als API-Aufrufe
Hier weichen Prognosemärkte am deutlichsten vom konventionellen API-Design ab. Wenn Sie eine Order auf Polymarket platzieren, senden Sie nicht nur Daten an einen Server – Sie erstellen eine kryptografisch signierte Nachricht, die eine durchsetzbare finanzielle Verpflichtung darstellt:
const response = await client.createAndPostOrder(
{
tokenID: "71321045679...",
price: 0.65,
size: 100,
side: Side.BUY,
},
{
tickSize: "0.01",
negRisk: false,
},
OrderType.GTC
);
Unter der Haube konstruiert das SDK eine EIP-712 typisierte Datenstruktur, signiert sie mit Ihrem privaten Schlüssel und übermittelt die Signatur zusammen mit der Order. Die Matching-Engine arbeitet Off-Chain, aber wenn Trades gematcht werden, werden sie On-Chain über Polygon unter Verwendung dieser Signaturen abgewickelt. Der Operator kann keine Trades fälschen oder Gelder bewegen – die signierte Nachricht ist die Autorisierung.
Dies ändert die Semantik dessen, was ein „API-Aufruf“ bedeutet. Normalerweise bedeutet das Absenden an einen Endpunkt „bitte tun Sie dies in meinem Namen“. Hier bedeutet das Absenden einer Order „hier ist ein signiertes Instrument, das diesen Trade autorisiert“. Die API ist kein Zwischenhändler, der Entscheidungen trifft – sie ist ein Relais für kryptografisch selbstautorisierende Nachrichten.
Für API-Designer außerhalb des Krypto-Bereichs ist die Erkenntnis folgende: Wenn die *Nutzlast selbst* die Autorisierung tragen kann, anstatt sich vollständig auf Transport-Layer-Anmeldeinformationen zu verlassen, erhalten Sie Nichtabstreitbarkeit und Überprüfbarkeit kostenlos. Finanzsysteme, juristische Dokumente und hochriskante Operationen sind alle Kandidaten für dieses Muster.
Muster 5: Explizite Ontologie im Datenmodell
Polymarket strukturiert seine Daten um zwei Objekte herum: Events und Markets. Die Unterscheidung ist wichtig.
Ein Event ist eine Frage: „Wer gewinnt das US-Senatsrennen 2026 in Pennsylvania?“ Es hat einen Titel, eine Kategorie, ein Auflösungsdatum. Ein Market ist ein spezifisches handelbares binäres Ergebnis innerhalb dieses Events: „Wird Bob Casey gewinnen?“ Ein Event kann viele Märkte enthalten.
{
"id": "501",
"title": "2026 Pennsylvania Senate Race",
"negRisk": true,
"markets": [
{ "id": "2301", "question": "Will Bob Casey win?", "outcomePrices": "[\"0.42\", \"0.58\"]" },
{ "id": "2302", "question": "Will Dave McCormick win?", "outcomePrices": "[\"0.35\", \"0.65\"]" },
{ "id": "2303", "question": "Will a third candidate win?", "outcomePrices": "[\"0.23\", \"0.77\"]" }
]
}
Dies ist eine explizite Ontologie – die API speichert nicht nur Daten, sie kodiert die *konzeptuellen Beziehungen* zwischen Entitäten. Preise werden als parallele Arrays dargestellt, wobei die Indexposition die Bindungskonvention ist: outcomes[0] entspricht outcomePrices[0]. Das negRisk-Flag auf Event-Ebene signalisiert, dass die Märkte innerhalb des Events Kapitalbeziehungen aufweisen, die in unabhängigen Märkten nicht existieren.
Die meisten APIs glätten diese Beziehungen. Polymarket legt sie offen, weil sie tragend für die Funktionsweise des Systems sind. Wenn Sie einen automatisierten Trader bauen und negRisk: true übersehen, erstellen Sie ein falsches Positionsmodell und verlieren potenziell Geld. Das API-Design macht die konzeptuelle Struktur sichtbar, sodass das Weglassen eine bewusste Entscheidung und kein stillschweigender Standard ist.
Muster 6: NegRisk — Kapitalbeziehungen als erstklassiges Anliegen
Das negRisk-Flag bei Events verweist auf eines der interessantesten API-Designmuster von Polymarket: die Programmierbarkeit finanzieller Äquivalenzen.
In einem standardmäßigen Multi-Outcome-Event ist jeder Markt unabhängig. Bei einem NegRisk-Event, bei dem genau ein Ergebnis gewinnen kann, besteht jedoch eine mathematische Beziehung zwischen den Positionen:
1 No-Token auf Ergebnis A ≡ 1 Yes-Token auf jedem anderen Ergebnis
Das ist nicht nur Mathematik – es ist in Smart Contracts implementiert und wird über die API zugänglich gemacht. Wenn Sie eine No-Position auf „Andere“ im Senatsrennen von Pennsylvania halten, können Sie diese konvertieren:
| Vorher | Nachher |
|---|---|
| 1× Nein (Andere) | 1× Ja (Casey) + 1× Ja (McCormick) |
Die API macht dies explizit: negRisk: true im Marktobjekt und negRisk: true ist in Ihren Orderoptionen erforderlich, wenn Sie diese Märkte handeln. Wenn Sie es falsch machen, wird Ihre Order abgelehnt oder falsch abgewickelt.
Das Designmuster hier ist die Kodierung von Domäneninvarianten als typisierte API-Felder, anstatt sie als Fußnoten in der Dokumentation zu belassen. Das NegRisk-Flag existiert nicht, weil es bequem ist, es zu haben – es existiert, weil das Weglassen zu falschem Verhalten führt. Wenn Ihre Domäne strenge Einschränkungen hat (nur ein Ergebnis kann gewinnen, Positionen haben Umrechnungsäquivalenzen), sollten diese Einschränkungen in der API-Oberfläche erscheinen, nicht nur in der Dokumentation.
Muster 7: Dynamische Tick-Größe als Marktstatus
Die meisten Finanz-APIs behandeln die Tick-Größe als statische Konfiguration. Die von Polymarket tut etwas Interessanteres: Die Tick-Größe ändert sich dynamisch basierend auf dem Marktpreis, und die API macht dies als Echtzeit-Ereignisstrom verfügbar.
Wenn der Preis eines Marktes die Extreme erreicht (über 0,96 oder unter 0,04), verringert sich die minimale Tick-Größe von 0,01 auf 0,001:
{
"event_type": "tick_size_change",
"asset_id": "65818619657...",
"old_tick_size": "0.01",
"new_tick_size": "0.001",
"timestamp": "100000000"
}
Die Begründung ist intuitiv: Bei extremen Wahrscheinlichkeiten stellt ein 1-Cent-Tick eine Bewegung von 25 % dar (von 0,04 auf 0,03). Das ist zu grob für eine aussagekräftige Preisfindung. Kleinere Ticks nahe den Extremen ermöglichen es dem Markt, Wahrscheinlichkeiten wie 97,3 % auszudrücken, anstatt auf 97 % zu runden.
Was dies als API-Designentscheidung bemerkenswert macht, ist, dass die Tick-Größe kein Parameter ist, den man einmal abruft – es ist ein *Zustand*, der sich ändert und verfolgt werden muss. Der WebSocket expose tick_size_change-Ereignisse genau so, dass Clients ihre Orderkonstruktionslogik konsistent mit dem aktuellen Marktstatus halten können. Wenn Sie die Tick-Größe fest codieren und dieses Ereignis verpassen, werden Ihre Orders abgelehnt.
Dies spiegelt ein breiteres Prinzip wider: API-Design für Finanzsysteme muss den Zustand als erstklassiges Konzept annehmen. Marktparameter sind nicht statisch. Auflösungsregeln ändern sich. Ergebnisse werden präzisiert. Die API muss diese Zustandsübergänge explizit kommunizieren und darf Clients nicht dazu überlassen, sie durch abgelehnte Anfragen zu entdecken.
Muster 8: Zwei WebSocket-Schichten für unterschiedliche Konsumentenprofile
Polymarket betreibt zwei separate WebSocket-Systeme, und das Verständnis warum, enthüllt ein Muster der Zielgruppensegmentierung.
Der Markt-Kanal (wss://ws-subscriptions-clob.polymarket.com/ws/market) ist für Handels-Konsumenten konzipiert. Abonnieren Sie nach Token-ID, erhalten Sie Orderbuch-Snapshots, Preisänderungen, Handelsausführungen und Tick-Größenänderungen. Alles ist auf Asset-IDs bezogen und für die Orderkonstruktion mit geringer Latenz optimiert:
{
"assets_ids": ["65818619657568813474341868652308942079804919287380422192892211131408793125422"],
"type": "market"
}
Der Echtzeit-Daten-Socket (wss://ws-live-data.polymarket.com) ist für ein völlig anderes Profil konzipiert. Er streamt Kommentare, Krypto-Preise von Binance und Chainlink, Aktienkurse und soziale Interaktionsereignisse. Abonnieren Sie nach Thema:
{
"action": "subscribe",
"subscriptions": [
{ "topic": "crypto_prices", "type": "update", "filters": "btcusdt,ethusd" }
]
}
Diese beiden Systeme bedienen Zielgruppen mit grundlegend unterschiedlichen Bedürfnissen. Ein Market Maker benötigt mikrosekundenrelevante Orderbuch-Deltas. Eine Benutzeroberfläche, die anzeigt, „was gerade auf Polymarket passiert“, benötigt Kommentar-Feeds und soziale Aktivitäten. Das Kombinieren würde bedeuten, entweder den Social Feed mit Latenzanforderungen auf Handelsniveau zu überentwickeln oder den Orderbuch-Feed mit Zuverlässigkeitsannahmen auf Social-Media-Niveau unterzuwickeln.
Die Lektion ist einfach, wird aber oft ignoriert: Wenn Ihre Echtzeit-Konsumenten deutlich unterschiedliche Latenztoleranzen, Datenvolumina und Fehlerarten haben, geben Sie ihnen eine separate Infrastruktur. Gemeinsame WebSocket-Endpunkte, die versuchen, mehrere Zwecke zu erfüllen, tendieren dazu, beim höchsten gemeinsamen Nenner für Komplexität und beim niedrigsten gemeinsamen Nenner für Leistung zu landen.
Was diese Muster gemeinsam haben
Das API-Design von Polymarket spiegelt eine bestimmte Philosophie wider: Die API soll die tatsächliche Struktur der Domäne sichtbar machen, nicht abstrahieren.
Die dreischichtige Architektur bildet reale Domänengrenzen ab. Der Public-First-Zugriff spiegelt wider, wie der Wert von Prognosemärkten funktioniert. Die zweistufige Authentifizierung spiegelt den realen Unterschied zwischen dem Nachweis der Identität und der Autorisierung einer Aktion wider. Orders als signierte Nachrichten kodieren die nicht-treuhänderische Garantie. Die Event/Market-Hierarchie und das NegRisk-Flag legen Beziehungen offen, die sonst unsichtbar wären. Dynamische Tick-Größen halten den Client-Zustand konsistent mit dem Marktstatus. Separate WebSocket-Schichten bedienen getrennte Zielgruppen.
Die meisten Ratschläge zum API-Design konzentrieren sich auf Ergonomie: einfach aufzurufen, konsistent in der Benennung, vorhersehbar in der Fehlerbehandlung. Die API von Polymarket tut all das – aber die interessanteren Entscheidungen betreffen die *Treue zur Domäne*. Wenn die Domäne eine bedeutsame Unterscheidung aufweist, macht die API diese sichtbar. Wenn die Domäne eine Einschränkung hat, setzt die API diese durch. Wenn die Domäne einen Zustand hat, der sich ändert, sendet die API dies aus.
Das Ergebnis ist eine API, die mehr von ihren Konsumenten verlangt, aber eine, bei der das richtige Verständnis bedeutet, dass Sie das System, auf dem Sie handeln, tatsächlich verstehen. Das ist kein Zufall – für einen Prognosemarkt, bei dem es gerade darum geht, dass Preise Informationen widerspiegeln, tut eine API, die Sie zwingt, die Struktur des Marktes zu verstehen, genau das, was sie sollte.