SHARKRULE / LEITFÄDEN

Polymarket Bot testen: Paper Trading und belastbare Prüffälle

Ein VPS, ein laufender Prozess und eine schöne Backtest-Kurve belegen noch keinen zuverlässigen Bot. Beginnen Sie mit konkreten Eingaben und erwarteten Entscheidungen. So werden Fehler prüfbar, bevor ein Signierer echte Orders senden kann.

Geprüft am 12. September 2026

Von SharkRule · Mit KI-Unterstützung erstelltes Lernmaterial

Replay, Paper Trading und Live-Test unterscheiden

Ein Replay spielt gespeicherte Ereignisse ab. Paper Trading verarbeitet Daten und protokolliert simulierte Entscheidungen. Ein Live-Test sendet echte Orders. Kennzeichnen Sie den Modus im Ergebnisbericht.

Für die folgenden Übungen bleibt der Signier- und Sendeadapter deaktiviert. Die Ausgabe ist ein lokaler Intent-Eintrag, keine Order. Historische Daten allein belegen weder eine vollständige Ausführungssimulation noch eine offizielle Testumgebung.

Eine fiktive Regel mit erwarteten Ergebnissen

Testparameter: höchstens zwölf Anteile, Preislimit 0,47 USD, maximales Datenalter 2.000 ms, Budget 5,70 USD und hypothetische Kostenreserve 0,20 USD. Diese Größen sind Softwareprüfdaten, keine Handelsempfehlung.

Im Normalfall zu 0,46 USD werden ausdrücklich elf Anteile angefordert: 5,06 USD plus 0,20 USD Reserve ergeben 5,26 USD. Zwölf zum gleichen Preis würden 5,72 USD kosten und müssen am Budget von 5,70 scheitern. Höchstens zwölf ist eine Obergrenze; die angeforderte Menge darf nicht stillschweigend geändert werden.

Minimale Abnahmematrix
EingabeErwartetes ErgebnisPrüfziel
Preis 0,46, frische Daten, genügend TiefeEin simulierter IntentNormalfall
Identisches Ereignis erneutKein zusätzlicher IntentDuplikatschutz
Datenalter 2.001 msKeine OrderAktualitätsgrenze
Bestes Verkaufsangebot 0,48Kein KaufPreislimit
Kalkulierter Betrag über 5,70Begründete SperreBudget
Neustart mit ungeklärter OrderPausiert bleibenWiederanlaufkontrolle

Ausführung nicht aus einem Chartkontakt erfinden

Im fiktiven Buch stehen vier Anteile zu 0,45 USD, sechs zu 0,47 und zehn zu 0,50. Bei Limit 0,47 sind nur zehn Anteile zulässig. Ein Simulator darf keine zwölf als ausgeführt verbuchen, nur weil ihr Durchschnitt unter dem Limit liegen würde.

Für eine ruhende Order braucht das Modell zusätzliche Annahmen zu Warteschlange und späteren Trades. Dass eine Kerze den Preis berührt hat, beweist keine Ausführung dieser Order. Fehlende Evidenz sollte als solche im Bericht stehen.

Testen Sie eine Stornierung mit konkurrierender Ausführung: fünf ausgeführt, Stornierung angefordert, weitere zwei ausgeführt. Der Endzustand muss sieben ausgeführte und fünf stornierte Anteile erhalten.

Informationsverfügbarkeit statt nur Ereigniszeit speichern

Protokollieren Sie, wann ein Ereignis stattfand und wann es für die Regel verfügbar war. Der Schlusskurs einer Kerze kann keine Entscheidung vor ihrem Abschluss rechtfertigen. Eine später veröffentlichte Korrektur stand zuvor ebenfalls nicht zur Verfügung.

Versionieren Sie Daten und Parameter. Nachträgliche Schwellenänderungen erfordern eine erneute Bewertung an getrennten Daten. Der Datensatz, mit dem die Regel angepasst wurde, ist keine unabhängige Bestätigung.

Ausfallfälle vor dem Test festlegen

Erwartungen müssen vor der Auswertung feststehen. Ein fehlgeschlagener Fall bleibt sichtbar, bis sein Fehler behoben oder seine Modellgrenze nachvollziehbar beschrieben ist.

  • Doppelte und falsch sortierte Nachrichten einspielen.
  • Datenstrom unterbrechen und neue Aktionen sperren lassen.
  • Teilausführung und Ablauf der Restorder modellieren.
  • Antwortverlust ohne automatischen Doppelauftrag prüfen.
  • Mit ungeklärtem Intent neu starten und Abgleich erzwingen.
  • Auch Nichtstun mit Begründung protokollieren.

Was der Prüfbericht tatsächlich belegt

Ein reproduzierbarer Bericht nennt Version, Eingaben, Uhr, Liquiditätsannahmen, Soll- und Ist-Ergebnis. Trennen Sie Programmfehler von Situationen, die das Modell nicht abbilden kann.

Die Beispiele dieser Seite wurden lokal auf Rechenwege und Entscheidungen mit fiktiven Daten geprüft. Das ist kein Nachweis einer gehandelten Strategie, von Rentabilität, realer Latenz oder einer verfügbaren SharkRule-Integration. Bestandene Simulationen ersetzen keine gesonderte Entscheidung über echte Ausführung.

Verwahrung, Berechtigungen und Zulässigkeit

Ohne Verwahrung bedeutet, dass Mittel in einer vom Nutzer kontrollierten Wallet bleiben. Handelsrechte, Risiken von Smart Contracts und mögliche Verluste entfallen dadurch nicht. SharkRule ist unabhängig von Polymarket; eine Zugehörigkeit oder Empfehlung durch Polymarket wird nicht behauptet. Dies ist Softwarewissen, keine Finanz- oder Anlageberatung. Für die Handelsberechtigung gelten die aktuellen geografischen Beschränkungen von Polymarket.

Aktuelle geografische Beschränkungen prüfen

Häufige Fragen

Brauche ich für diese Tests Guthaben?

Nein. Die Übung nutzt fiktive Eingaben und lokale Ausgaben ohne Signierung oder Versand.

Reicht die Gamma-API oder ein Preisverlauf als Ausführungsnachweis?

Ein Datenzugang allein reicht nicht. Tiefe, Warteschlange, Zeitpunkte und Orderzustände benötigen passende zusätzliche Daten und ein offengelegtes Modell.

Beweist ein erfolgreicher Backtest Live-Tauglichkeit?

Nein. Er hängt von Daten und Annahmen ab. Die beschriebenen Tests sollen Fehler und Grenzen aufdecken, keine Ergebnisse garantieren.

Ihr Arbeitsblatt

Kopie speichern und lokal ausfüllen. Nur öffentliche Kennungen verwenden, niemals Passwörter, private Schlüssel, Wiederherstellungswörter oder API-Geheimnisse. Das Dokument verbindet kein Konto und sendet keine Orders.

Arbeitsblatt herunterladen (.txt)

Quellen und weiterführende Informationen

Wie dieser Leitfaden entstand

Mit KI-Unterstützung anhand der verlinkten offiziellen Quellen erstellt. Zahlenbeispiele und Entscheidungsgrenzen wurden mit lokalen deterministischen Prüffällen kontrolliert. Es gab keine echten Trades, keinen Rentabilitäts-Backtest und keine unabhängige Expertenprüfung. Dokumentationsstand: 12. September 2026; spätere Änderungen bei den verlinkten Anbietern prüfen.