Yield Farming mit 86% APY? So nutzen Sie Bots für automatisiertes Handeln auf Polymarket

Originaltitel: Ich habe einen Polymarket-Bot gebaut und verschiedene Parametereinstellungen getestet – hier sind die Ergebnisse.

Originalautor: @the_smart_ape, Krypto-Researcher

Originalübersetzung: Bitpush News

Vor einigen Wochen beschloss ich, meinen eigenen Polymarket-Bot zu entwickeln. Die vollständige Version nahm mehrere Wochen in Anspruch.

Ich war bereit, diesen Aufwand zu betreiben, da es auf Polymarket tatsächlich eine Effizienzlücke gibt. Obwohl einige Bots am Markt diese Ineffizienzen bereits ausnutzen, ist dies bei weitem nicht genug, und die Möglichkeiten auf diesem Markt sind noch immer weitaus größer als die Anzahl der Bots.

Logik des Bot-Aufbaus

Die Logik des Bots basiert auf einer Reihe von Strategien, die ich in der Vergangenheit manuell ausgeführt habe und die ich zur Effizienzsteigerung automatisiert habe. Der Bot läuft auf dem „BTC 15-Minuten UP/DOWN“-Markt.

Der Bot führt ein Echtzeit-Überwachungsprogramm aus, das automatisch zur aktuellen BTC 15-Minuten-Runde wechseln kann, das beste Bid/Ask über ein WebSocket optimiert, eine feste Terminal-UI anzeigt und eine umfassende Steuerung über Textbefehle ermöglicht.

Im manuellen Modus können Sie Aufträge direkt platzieren.

buy up <usd> / buy down <usd>: Kauf eines bestimmten Betrags in USD.

buyshares up <shares> / buyshares down <shares>: Kauf einer exakten Anzahl von Shares unter Verwendung eines benutzerfreundlichen LIMIT + GTC (Good 'Til Canceled) Auftrags, ausgeführt zum aktuell besten Ask-Preis.

Der automatische Modus führt eine wiederkehrende Zwei-Phasen-Schleife aus.

Zuerst beobachtet er nur Preisbewegungen innerhalb der windowMin-Minuten zu Beginn jeder Runde. Wenn eine Seite schnell genug fällt (und in etwa 3 Sekunden einen Rückgang von mindestens movePct erreicht), löst dies „Phase 1“ aus und kauft die Seite, die den starken Rückgang erlebt hat.

Nach Abschluss von Phase 1 kauft der Bot nie wieder dieselbe Seite. Er wartet auf die „Zweite Phase (Phase 2, d. h. Hedge)“ und löst nur aus, wenn die folgende Bedingung erfüllt ist: leg1EntryPrice + oppositeAsk <= sumTarget.

Wenn diese Bedingung erfüllt ist, kauft er die entgegengesetzte Seite. Nach Abschluss von Phase 2 endet der Zyklus, der Bot kehrt in den Beobachtungsmodus zurück und wartet mit denselben Parametern auf das nächste Flash-Crash-Signal.

Wenn sich die Runde während des Zyklus ändert, bricht der Bot den offenen Zyklus ab und startet in der nächsten Runde mit denselben Einstellungen neu.

Die Parametereinstellungen für den Auto-Modus sind wie folgt: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: Positionsgröße für den zweistufigen Handel.

· sum: Schwellenwert für zulässiges Hedging.

· move (movePct): Flash-Crash-Schwellenwert (z. B. 0.15 = 15%).

· windowMin: Zeit ab Beginn jeder Runde, um die Ausführung von Phase 1 zu ermöglichen.

Backtesting

Die Logik des Bots ist einfach: Warten auf einen heftigen Flash-Crash, Kauf der Seite, die gerade gefallen ist, dann Warten auf die Preisstabilisierung und Absicherung durch Kauf der entgegengesetzten Seite, um sicherzustellen, dass priceUP + priceDOWN < 1 ist.

Aber diese Logik muss getestet werden. Ist sie auf lange Sicht wirklich effektiv? Noch wichtiger ist, dass der Bot viele Parameter hat (shares, sum, move percentage, window minutes usw.). Welcher Parametersatz ist optimal und maximiert den Gewinn?

Mein erster Gedanke war, den Bot eine Woche lang live laufen zu lassen und die Ergebnisse zu beobachten. Das Problem ist, dass dies zu lange dauert und nur einen Satz von Parametern testen kann, während ich viele testen muss.

Mein zweiter Gedanke war ein Backtest unter Verwendung von historischen Online-Daten der Polymarket CLOB API. Leider liefert der Endpunkt für historische Daten für den BTC 15-Minuten-Up/Down-Markt durchweg leere Datensätze. Ohne historische Preisticks kann der Backtest keinen „ca. 3-sekündigen Flash-Crash“ erkennen, Phase 1 nicht auslösen und führt unabhängig von den verwendeten Parametern zu 0 Zyklen und 0% ROI.

Nach weiterer Untersuchung stellte ich fest, dass auch andere Benutzer beim Abrufen historischer Daten für bestimmte Märkte auf dasselbe Problem stießen. Ich testete andere Märkte, die tatsächlich historische Daten lieferten, und kam zu dem Schluss, dass für diesen speziellen Markt einfach keine historischen Daten gespeichert wurden.

Aufgrund dieser Einschränkung ist der einzige zuverlässige Weg, diese Strategie zu backtesten, die Erstellung meines eigenen historischen Datensatzes durch Aufzeichnung der besten Ask-Preise in Echtzeit, während der Bot läuft.

Der Rekorder schreibt Snapshots auf die Festplatte, einschließlich der folgenden:

· Zeitstempel

· Round Slug

· Verbleibende Sekunden

· UP/DOWN Token ID

· UP/DOWN Best Ask-Preis

Anschließend spielt der „aufgezeichnete Backtest“ diese Snapshots ab und wendet deterministisch dieselbe automatisierte Logik an. Dies stellt sicher, dass die hochfrequenten Daten erhalten werden, die zur Erkennung von Flash-Crashes und Hedge-Bedingungen erforderlich sind.

Über 4 Tage sammelte ich insgesamt 6 GB an Daten. Ich hätte mehr aufzeichnen können, aber ich hielt dies für ausreichend, um verschiedene Parametersätze zu testen.

Ich begann mit dem Testen dieses Parametersatzes:

· Anfangskapital: $1.000

· 20 Shares pro Trade

· sumTarget = 0.95

· Flash-Crash-Schwellenwert = 15%

· windowMin = 2 Minuten

Ich habe außerdem eine konstante Gebühr von 0,5% und einen Spread von 2% angewendet, um in einem konservativen Szenario zu bleiben.

Der Backtest zeigte einen ROI von 86%, wodurch aus $1.000 in nur wenigen Tagen $1.869 wurden.

Als nächstes testete ich einen aggressiveren Parametersatz:

· Anfangskapital: $1.000

· 20 Shares pro Trade

· sumTarget = 0.6

· Flash-Crash-Schwellenwert = 1%

· windowMin = 15 Minuten

Ergebnis: Nach 2 Tagen hatte die Investition eine Rendite von -50%.

Dies zeigt deutlich, dass die Parameterauswahl der kritischste Faktor ist. Sie kann Ihnen viel Geld einbringen oder zu erheblichen Verlusten führen.

Einschränkungen des Backtestings

Selbst unter Einbeziehung von Kosten und Spreads hat das Backtesting seine Grenzen.

· Erstens verwendet es nur Daten von wenigen Tagen, was möglicherweise nicht ausreicht, um eine umfassende Marktperspektive zu gewinnen.

· Es stützt sich auf aufgezeichnete Snapshots der optimalen Verkaufspreise; in der Realität können Aufträge teilweise oder zu anderen Preisen ausgeführt werden. Außerdem werden die Tiefe des Orderbuchs und das verfügbare Volumen nicht modelliert.

· Mikro-Schwankungen unter einer Sekunde werden nicht erfasst (Daten werden jede Sekunde abgetastet). Obwohl das Backtesting Zeitstempel auf 1-Sekunden-Ebene hat, kann zwischen jeder Sekunde viel passieren.

· Slippage ist beim Backtesting konstant, ohne variable Verzögerungen (z. B. 200–1500 Millisekunden) oder Spitzen bei Netzwerküberlastungen zu simulieren.

· Es wird angenommen, dass jedes Handelssegment „sofort“ ausgeführt wird (keine Auftragswarteschlangen, keine ruhenden Aufträge).

· Kosten werden einheitlich berechnet, während sie in der Realität abhängen können von: Markt/Token, Maker-Taker, Gebührenstufen oder Bedingungen.

Um einen pessimistischen (vorsichtigen) Ansatz beizubehalten, habe ich eine Regel angewendet: Wenn Phase 2 nicht vor Marktschluss ausgeführt wird, gilt Phase 1 als Totalverlust.

Obwohl dies absichtlich konservativ ist, entspricht es nicht immer der Realität:

· Manchmal kann Phase 1 vorzeitig geschlossen werden,

· Manchmal endet sie im Geld (ITM) und gewinnt,

· Manchmal kann der Verlust eher teilweise als total sein.

Obwohl der Verlust überschätzt werden kann, bietet dies ein praktisches „Worst-Case“-Szenario.

Am wichtigsten ist, dass das Backtesting nicht die Auswirkungen Ihrer großen Aufträge auf das Orderbuch simulieren oder räuberisches Verhalten anderer Händler anziehen kann. In der Realität kann Ihr Auftrag:

· Das Orderbuch stören,

· Andere Händler anziehen oder abstoßen,

· Nichtlineare Slippage verursachen.

Das Backtesting geht davon aus, dass Sie ein reiner Liquiditätsentnehmer (Price Taker) ohne Einfluss sind.

Schließlich simuliert es keine Ratenbegrenzungen, API-Fehler, Auftragsablehnungen, Halte, Timeouts, Wiederverbindungen oder Situationen, in denen der Bot beschäftigt ist und Signale verpasst.

Backtesting ist äußerst wertvoll für die Identifizierung eines guten Parameterbereichs, aber es ist keine 100%ige Garantie, da einige reale Effekte nicht modelliert werden können.

Infrastruktur

Ich plane, diesen Bot auf einem Raspberry Pi auszuführen, um keine Ressourcen auf meinem Hauptrechner zu verbrauchen und ihn rund um die Uhr laufen zu lassen.

Es gibt jedoch noch erheblichen Verbesserungsspielraum:

· Die Verwendung von Rust anstelle von JavaScript wird eine wesentlich bessere Leistung und Verarbeitungszeit bieten.

· Der Betrieb eines dedizierten Polygon RPC Nodes wird die Latenz weiter reduzieren.

· Die Bereitstellung auf einem VPS in der Nähe des Polymarket-Servers wird die Latenz ebenfalls erheblich reduzieren.

Ich bin sicher, dass es andere Optimierungsmethoden gibt, die ich noch nicht entdeckt habe. Derzeit lerne ich Rust, da es eine unverzichtbare Sprache in der Web3-Entwicklung wird.

Link zum Originalartikel