Veröffentlichen
BitHappy
·
--
Die Fallstricke des Prognosemarkt-Bots ～
Vor ein paar Tagen sah ich, dass der Kollege 0xKaKa03 einen Beitrag zur Verteidigung des Orderbuchs von Polymarket verfasst hat, der vielen Freunden, die Bots betreiben, eine Warnung gegeben hat.
Basierend auf einigen persönlichen Erfahrungen aus der letzten Zeit möchte ich einige Fallstricke und Erfahrungen ergänzen, die für alle von Nutzen sein könnten.
➤ Zum Beispiel:
1/ WS-Verbindung instabil:
Früher, als ich historische Daten und Echtzeit-Orderbücher sammelte, hatte ich häufig Probleme mit der WS-Unterbrechung, was zu Datenlücken führte. Die konkreten Probleme, die ich hatte, waren, dass die offizielle WS manchmal plötzlich abbrach oder unvollständig pushte, was dazu führte, dass der Bot auf der Grundlage eines unvollständigen Orderbuchs Bestellungen aufgab, was ein großes Risiko darstellt. Man kann die REST API als Backup zur Abfrage verwenden.
Dieses Problem könnte jedoch auch mit dem Server und dem Programmdesign zusammenhängen, da ich einen AWS-Server in Tokio verwendet habe.
2/ Zustandsmaschine + Mehrquellenprüfung + Warnmechanismen:
Beim Ausführen von Strategien kommt es leicht zu Problemen mit der API. Ich empfehle, eine Zustandsmaschine zur Überwachung des gesamten Bestellprozesses (Bestellung → Bestätigung → Matching → On-Chain-Abrechnung) zu verwenden und mehrere Warnschwellenwerte festzulegen, wie z.B. fehlgeschlagene Statuswechsel (z.B. Bestellung lange Zeit im Pending), plötzliche Änderungen im Orderbuch, Preisabweichungen, die die Erwartungen übersteigen.
Sobald dies ausgelöst wird, sofort neue Bestellungen pausieren und die Risiko-Position glattstellen.
Darüber hinaus kann man auch Mehrquellenabgleiche durchführen, indem man sowohl WS als auch API verwendet und zusätzlich On-Chain-Ereignisse sowie die Abfragen von The Graph zur Kreuzvalidierung kombiniert.
3/ Serververzögerung:
Bei Hochfrequenz-Bots ist die Verzögerung der Programmlogik (die tatsächliche Differenz liegt nur im Mikrosekunden- bis Millisekundenbereich) eigentlich nicht der Engpass; das wirkliche Problem sind die Netz- und Serververzögerungen.
Ich habe getestet, dass selbst wenn man japanische Knoten auswählt, zwischen ByVirt und AWS JP mehr als 200 ms liegen, was in einem wettbewerbsintensiven Markt tödlich sein kann.
Insgesamt gibt es viele Chancen im Prognosemarkt, aber die Infrastruktur wird noch verbessert, und bei der Ausführung von Bots ist defensives Design wichtiger als offensives Logik.
Priorität hat der Kapitalerhalt, bevor man nach Gewinn strebt, schließlich gibt es auch noch Erwartungen an Airdrops.
Hinweis: Die obigen Informationen sind lediglich zur Information, keine Anlageberatung, bitte machen Sie unbedingt Ihre eigenen Recherchen!
DeFi-Enthusiast: BitHappy
Vor ein paar Tagen sah ich, dass der Kollege 0xKaKa03 einen Beitrag zur Verteidigung des Orderbuchs von Polymarket verfasst hat, der vielen Freunden, die Bots betreiben, eine Warnung gegeben hat.
Basierend auf einigen persönlichen Erfahrungen aus der letzten Zeit möchte ich einige Fallstricke und Erfahrungen ergänzen, die für alle von Nutzen sein könnten.
➤ Zum Beispiel:
1/ WS-Verbindung instabil:
Früher, als ich historische Daten und Echtzeit-Orderbücher sammelte, hatte ich häufig Probleme mit der WS-Unterbrechung, was zu Datenlücken führte. Die konkreten Probleme, die ich hatte, waren, dass die offizielle WS manchmal plötzlich abbrach oder unvollständig pushte, was dazu führte, dass der Bot auf der Grundlage eines unvollständigen Orderbuchs Bestellungen aufgab, was ein großes Risiko darstellt. Man kann die REST API als Backup zur Abfrage verwenden.
Dieses Problem könnte jedoch auch mit dem Server und dem Programmdesign zusammenhängen, da ich einen AWS-Server in Tokio verwendet habe.
2/ Zustandsmaschine + Mehrquellenprüfung + Warnmechanismen:
Beim Ausführen von Strategien kommt es leicht zu Problemen mit der API. Ich empfehle, eine Zustandsmaschine zur Überwachung des gesamten Bestellprozesses (Bestellung → Bestätigung → Matching → On-Chain-Abrechnung) zu verwenden und mehrere Warnschwellenwerte festzulegen, wie z.B. fehlgeschlagene Statuswechsel (z.B. Bestellung lange Zeit im Pending), plötzliche Änderungen im Orderbuch, Preisabweichungen, die die Erwartungen übersteigen.
Sobald dies ausgelöst wird, sofort neue Bestellungen pausieren und die Risiko-Position glattstellen.
Darüber hinaus kann man auch Mehrquellenabgleiche durchführen, indem man sowohl WS als auch API verwendet und zusätzlich On-Chain-Ereignisse sowie die Abfragen von The Graph zur Kreuzvalidierung kombiniert.
3/ Serververzögerung:
Bei Hochfrequenz-Bots ist die Verzögerung der Programmlogik (die tatsächliche Differenz liegt nur im Mikrosekunden- bis Millisekundenbereich) eigentlich nicht der Engpass; das wirkliche Problem sind die Netz- und Serververzögerungen.
Ich habe getestet, dass selbst wenn man japanische Knoten auswählt, zwischen ByVirt und AWS JP mehr als 200 ms liegen, was in einem wettbewerbsintensiven Markt tödlich sein kann.
Insgesamt gibt es viele Chancen im Prognosemarkt, aber die Infrastruktur wird noch verbessert, und bei der Ausführung von Bots ist defensives Design wichtiger als offensives Logik.
Priorität hat der Kapitalerhalt, bevor man nach Gewinn strebt, schließlich gibt es auch noch Erwartungen an Airdrops.
Hinweis: Die obigen Informationen sind lediglich zur Information, keine Anlageberatung, bitte machen Sie unbedingt Ihre eigenen Recherchen!
DeFi-Enthusiast: BitHappy
Haftungsausschluss: Die hier bereitgestellten Informationen enthalten Meinungen Dritter und/oder gesponserte Inhalte und stellen keine Finanzberatung dar. Siehe AGB.