Der menschliche Entwicklung an Codex fehlt zu weniger als 1%!
Gestern habe ich gerade erst die API bekommen und ein bisschen Zeit damit verbracht, ein Order-Posting-Skript zu bauen
Gesamtvermögen zu Beginn des Kontos: 311,8 u
Eine Nacht laufen lassen: 8k Handelsvolumen gemacht und dabei 1,31 u verdient
So hoch sind die „Kosten“ der Punkte – eigentlich negativ
Das liegt vor allem daran, dass die Liquidität auf der Plattform gerade richtig gut ist
Für so ein Skript muss man ziemlich viele Dinge berücksichtigen:
- Welche Tasks können parallel laufen und welche Aktionen müssen seriell sein?
Das Lesen kann parallel erfolgen, aber das Senden von Orders und das Stornieren sollte besser seriell sein. Sonst passiert es leicht, dass eine Order gerade erst platziert wurde und dann von einem anderen Thread fälschlich gelöscht/storniert oder doppelt gepostet wird.
- Soll man BUY und SELL in getrennte Threads aufteilen?
BUY muss Markt und Orderbook scannen und ist eher langsam; SELL muss die Positionen im Konto überwachen und braucht schnelle Reaktion. Wenn man sie trennt, wird SELL nicht durch einen vollständigen BUY-Scan blockiert.
- Wie soll man den lokalen State designen?
Man kann sich nicht nur auf API „open orders“ verlassen, weil der Börsenstatus nicht in Echtzeit konsistent ist. Nach einem erfolgreichen create order kann es ein paar Sekunden dauern, bis „open orders“ gefunden werden. Der lokale State muss kurzfristige Dubletten verhindern, doppelte Submits verhindern und fälschliches Aufräumen abfedern.
- Wie geht man mit eventual consistency um?
Eine gerade erstellte Order darf nicht schon allein deshalb als ungültig gelten, weil sie in der nächsten Sekunde bei der Abfrage von „open orders“ nicht auftaucht. Man sollte ein Waiting-Window setzen, z. B. 30–60 Sekunden, damit der Synchronisations-Thread für das Konto die neue Order nicht versehentlich entfernt.
- Wie nimmt man den Orderpreis?
Yes/No und Over/Under als „umgekehrte Outcomes“ lassen sich leicht falsch berechnen. Besonders bei SELL: Am besten den aktuellen Outcome der Position als bestAsk nehmen, statt blind die Yes-Seite aus dem Orderbook zu ergänzen.
- Wie geht man mit der Präzision bei den Anteilen um?
Frontend zeigt 17,86 an, aber das heißt nicht, dass man real genau 17,86 auch verkaufen kann. Die Ordermenge muss nach unten abgeschnitten werden (truncate), nicht gerundet. Sonst kommt es zu „insufficient shares“.
- Wie klassifiziert man API-Ausnahmen?
hash mismatch, unzureichendes Guthaben, unzureichende Anteile, Verbindungsabbruch zum entfernten System, Response-Abschnitt/Trunkierung, Verzögerung bei der Order-Synchronisierung – die Behandlungsweise ist jeweils unterschiedlich. Man darf nicht einfach unendlich oft retryen.
- Wie schreibt man die Risikokontrollgrenzen?
Kein Market-Sell, nicht „taker“ fressen, post-only, den BUY-Bereich begrenzen, Buy-Orders vor dem Start wieder stornieren – all das muss zu harten Constraints im Code werden.
Man sagt nicht, dass man mit KI ganz beiläufig ein System bauen kann, das langfristig stabil läuft und zuverlässig lieferbar ist. Man muss unbedingt aus Engineering-Sicht Stabilitätstests und Risk-Controls sauber umsetzen.
Interessierte können sich gern zum Austausch dazu gesellen～
@Predictdotfun
Gestern habe ich gerade erst die API bekommen und ein bisschen Zeit damit verbracht, ein Order-Posting-Skript zu bauen
Gesamtvermögen zu Beginn des Kontos: 311,8 u
Eine Nacht laufen lassen: 8k Handelsvolumen gemacht und dabei 1,31 u verdient
So hoch sind die „Kosten“ der Punkte – eigentlich negativ
Das liegt vor allem daran, dass die Liquidität auf der Plattform gerade richtig gut ist
Für so ein Skript muss man ziemlich viele Dinge berücksichtigen:
- Welche Tasks können parallel laufen und welche Aktionen müssen seriell sein?
Das Lesen kann parallel erfolgen, aber das Senden von Orders und das Stornieren sollte besser seriell sein. Sonst passiert es leicht, dass eine Order gerade erst platziert wurde und dann von einem anderen Thread fälschlich gelöscht/storniert oder doppelt gepostet wird.
- Soll man BUY und SELL in getrennte Threads aufteilen?
BUY muss Markt und Orderbook scannen und ist eher langsam; SELL muss die Positionen im Konto überwachen und braucht schnelle Reaktion. Wenn man sie trennt, wird SELL nicht durch einen vollständigen BUY-Scan blockiert.
- Wie soll man den lokalen State designen?
Man kann sich nicht nur auf API „open orders“ verlassen, weil der Börsenstatus nicht in Echtzeit konsistent ist. Nach einem erfolgreichen create order kann es ein paar Sekunden dauern, bis „open orders“ gefunden werden. Der lokale State muss kurzfristige Dubletten verhindern, doppelte Submits verhindern und fälschliches Aufräumen abfedern.
- Wie geht man mit eventual consistency um?
Eine gerade erstellte Order darf nicht schon allein deshalb als ungültig gelten, weil sie in der nächsten Sekunde bei der Abfrage von „open orders“ nicht auftaucht. Man sollte ein Waiting-Window setzen, z. B. 30–60 Sekunden, damit der Synchronisations-Thread für das Konto die neue Order nicht versehentlich entfernt.
- Wie nimmt man den Orderpreis?
Yes/No und Over/Under als „umgekehrte Outcomes“ lassen sich leicht falsch berechnen. Besonders bei SELL: Am besten den aktuellen Outcome der Position als bestAsk nehmen, statt blind die Yes-Seite aus dem Orderbook zu ergänzen.
- Wie geht man mit der Präzision bei den Anteilen um?
Frontend zeigt 17,86 an, aber das heißt nicht, dass man real genau 17,86 auch verkaufen kann. Die Ordermenge muss nach unten abgeschnitten werden (truncate), nicht gerundet. Sonst kommt es zu „insufficient shares“.
- Wie klassifiziert man API-Ausnahmen?
hash mismatch, unzureichendes Guthaben, unzureichende Anteile, Verbindungsabbruch zum entfernten System, Response-Abschnitt/Trunkierung, Verzögerung bei der Order-Synchronisierung – die Behandlungsweise ist jeweils unterschiedlich. Man darf nicht einfach unendlich oft retryen.
- Wie schreibt man die Risikokontrollgrenzen?
Kein Market-Sell, nicht „taker“ fressen, post-only, den BUY-Bereich begrenzen, Buy-Orders vor dem Start wieder stornieren – all das muss zu harten Constraints im Code werden.
Man sagt nicht, dass man mit KI ganz beiläufig ein System bauen kann, das langfristig stabil läuft und zuverlässig lieferbar ist. Man muss unbedingt aus Engineering-Sicht Stabilitätstests und Risk-Controls sauber umsetzen.
Interessierte können sich gern zum Austausch dazu gesellen～
@Predictdotfun
