Damit schließt eine kurze Serie über den Aufbau von Freya Finance ab. Statt die Artikel zu wiederholen, steht hier, was ich mir zu Beginn tatsächlich sagen würde, geordnet danach, wie teuer jede einzelne Lektion war.
Der rote Faden ist unbequem: Fast keiner dieser Fehler hat sich angekündigt. Sie erzeugten plausible Zahlen, gültig aussehende Orders und Bildschirme, die korrekt wirkten. In einem System, das mit dem Geld anderer handelt, ist der Bug, der eine Ausnahme wirft, die freundliche Sorte.
Das Wichtigste
- APIs von Drittanbietern versagen leise. Ein HTTP 200, der weniger Daten liefert als angefragt, ist der Fehlerfall, gegen den Sie planen sollten, nicht der 500er.
- Testen Sie den Simulator, bevor Sie irgendetwas testen, das er simuliert. Ein defekter Simulator liefert Zahlen, die genau wie korrekte aussehen.
- Berichten Sie, was Sie nicht simulieren konnten. Ein Ergebnis mit einer benannten Lücke ist mehr wert als ein sauber aussehendes Ergebnis, das stillschweigend eine Bedingung fallen ließ.
- Präzision ist ein Fachgebiet, keine Hilfsfunktion. Schrittweiten, Tick-Größen und Mindestwerte unterscheiden sich je nach Paar, Börse und Markttyp.
- Wählen Sie Beschränkungen früh. Die Entscheidung, niemals Nutzergelder zu verwahren, hat eine ganze Kategorie von Problemen gestrichen, statt sie zu lösen.
- Prüfen Sie in einer Geldoberfläche, welche Gesten die Plattform als Eingaben behandelt. Ein Mausrad über einem fokussierten Zahlenfeld ist eine davon.
1. Gehen Sie davon aus, dass jede API manchmal falsch erfolgreich ist
Die teuerste Annahme, die ich getroffen habe, war, dass eine fehlgeschlagene Anfrage wie ein Fehlschlag aussehen würde.
Börsen unter Last liefern HTTP 200 mit weniger Candles als angefragt, ohne Fehlerfeld, ohne Warnung. Einer unserer Deep-Backtests forderte rund 536,000 Candles an und erhielt 58,000. Dieselbe Anfrage lieferte eine Stunde später den vollständigen Satz. Nichts in der Antwort unterschied die beiden.
Wenn Sie nicht prüfen, simuliert die Engine eine Strategie über einen Bruchteil der beabsichtigten Historie und meldet eine selbstbewusste Zahl. Das ist schlimmer als ein Absturz, denn ein Absturz ist ehrlich.
Daraus ergaben sich zwei Regeln: Validieren Sie die Struktur einer erfolgreichen Antwort, nicht nur ihren Statuscode, und unterscheiden Sie vorübergehende Fehler von dauerhaften, bevor Sie entscheiden, was zu tun ist. Sie sehen im Moment ihres Auftretens identisch aus und verdienen entgegengesetzte Reaktionen.
Die ganze Geschichte: was ich unterschätzt habe
2. Testen Sie den Simulator, nicht die Strategie
Jeder Instinkt drängt Sie, die Strategielogik zu testen, denn das ist der interessante Teil. Die Falle: Ein defekter Simulator erzeugt eine Ausgabe, die von der eines funktionierenden nicht zu unterscheiden ist. Ein Lauf, der stillschweigend ein Zehntel der Daten verarbeitet hat, liefert trotzdem eine Zahl. Ein Lauf, dessen Ausstiege nie ausgewertet wurden, liefert eine verdächtig flache.
Die Wende kam, indem wir auf Dinge prüften, die die Strategie nicht verändern kann: dass die verarbeiteten Candles zu den abgerufenen passen, dass ein Lauf über einen bekannten Zeitraum diesen tatsächlich abdeckt, dass eine Konfiguration, die garantiert auslöst, auch Trades erzeugt.
Wenn diese Invarianten halten, ist ein seltsames Ergebnis ein echter Befund. Wenn nicht, ist das Ergebnis nur Rauschen im feinen Zwirn.
3. Berichten Sie, was Sie nicht simulieren konnten
Dies ist eher eine Designentscheidung als ein Bug, und ich halte sie für die am meisten unterschätzte.
Manche Bedingungen lassen sich nicht wiederholen. Ein externes Webhook-Signal hat keine historische Aufzeichnung. Der verlockende Schritt ist, es zu überspringen und den Rest auszuwerten, was die Ausgabe vollständig aussehen lässt.
Sehen Sie, was das mit einer Strategie macht, die A UND B verlangt. Wenn B nicht simuliert werden kann, entscheidet A allein, sodass der simulierte Bot dort einsteigt, wo der echte draußen geblieben wäre. Der Fehler ist nicht zufällig: Das Fallenlassen einer Bedingung unter UND-Logik kann nur mehr Trades erzeugen als in der Realität, sodass die Verzerrung jedes einzelne Mal auf ein besser aussehendes Ergebnis zeigt.
Wir führen die Simulation weiterhin aus, aber das Ergebnis trägt eine ausdrückliche Warnung, die benennt, was übersprungen wurde. Ein Simulator, der nicht laut scheitern kann, wird leise scheitern, und leises Scheitern bei etwas, das Zahlen produziert, ist der schlimmste Fehlerfall überhaupt.
Die ganze Geschichte: warum Backtests lügen
4. Eine glatte Equity-Kurve ist eine Frage, keine Antwort
Verwandt, und es lohnt sich, das gesondert zu behandeln, weil es Menschen täuscht statt Code.
Eine DCA-Order-Leiter ohne Stop Loss realisiert fast nie einen Verlust. Sie hält und kauft nach. Also sind geschlossene Trades fast alle Gewinner, die Gewinnrate sieht ausgezeichnet aus, und die Equity-Kurve ist eine ordentliche Treppe.
Das Risiko ist nicht verschwunden. Es wurde aufgeschoben, und der Aufschub hat eine harte Grenze: das Kapital, das für weitere Sicherheitsorders übrig bleibt. Die nützliche Frage ist nicht „Wie groß war der Drawdown?", sondern „Wenn der Preis weiter dagegen läuft, ab welchem Punkt geht der Strategie der Raum aus?"
Der Drawdown selbst braucht dieselbe Skepsis. Er wird gegen das zugewiesene Kapital auf seinem Höchststand gemessen, sodass derselbe Verlust von 200 USDT bei einer Zuweisung von 500 USDT als 40% erscheint und bei 5,000 als 4%. Zwei identisch handelnde Bots können völlig unterschiedliche Zahlen anzeigen.
Die ganze Geschichte: Drawdown verstehen
5. Präzision ist ein Fachgebiet, keine Hilfsfunktion
Ich habe „Mengen auf gültige Schritte runden" als eine einzige Hilfsfunktion verbucht. Es ist eine ganze Kategorie von Arbeit, und sie versteckt sich an einer Stelle, an der Fehler Geld kosten.
Fließkomma ist der Anfang: 0.29 mit einem Schritt von 0.01 zu skalieren ergibt 28.999999999999996, was still einen ganzen Schritt zu tief abrundet, hin zu einer kleineren Order.
Dann sind sich die Börsen über die Regeln selbst uneins. Eine prüft den Orderwert in USDT, eine prüft die Kontraktanzahl ganz ohne Wertprüfung, eine prüft beides. Unser schlimmster Bug in diesem Bereich entstand, weil wir einen Mindestwert erfunden haben, den eine Börse gar nicht hat, und dann gültige Orders daran abwiesen. Das verräterische Zeichen war im Nachhinein, dass unsere Version der Beschränkung vom Preis abhing, die echte aber nicht.
Überall, wo Sie eine einzige Konstante für etwas schreiben, das die Börse pro Paar definiert, schreiben Sie einen Bug mit Zeitzünder.
Die ganze Geschichte: Fließkomma wird Sie Geld kosten
6. Wählen Sie Ihre Beschränkungen früh
Die letzte ist kein Fehler. Es ist eine Entscheidung, deren Folgen ich im positiven Sinne unterschätzt habe.
Freya verwahrt niemals das Handelskapital der Nutzer. Schlüssel tragen Lese- und Handelsrechte, niemals Abhebung, und ein Schlüssel, der mit Abhebungsrecht ankommt, wird abgelehnt und nicht etwa angenommen und ignoriert. Dieser Unterschied wiegt schwerer, als er klingt: „Wir werden nicht abheben" ist eine Aussage über unser Verhalten, die ein Nutzer nicht überprüfen kann, während „der Schlüssel kann nicht abheben" von der Börse durchgesetzt wird und vom Nutzer in seinen eigenen Einstellungen prüfbar ist.
Ich hatte erwartet, dass dies ein Marketingargument wird. Es stellte sich als architektonisch heraus und machte das System kleiner: kein Verwahrungsbuch, kein Abgleich, keine Abhebungswarteschlange, keine Cold-Storage-Richtlinie für Handelskapital. Eine ganze Klasse der schwierigsten Probleme in Finanzsoftware fehlt, weil wir das, was sie erzeugt, nie übernommen haben.
Was an seine Stelle tritt, ist enger und schärfer: Das System muss in Echtzeit korrekt sein, denn es kann nichts rückgängig machen. Eine Order, die auf dem Börsenkonto eines anderen ausgeführt wurde, ist endgültig.
Die ganze Geschichte: nicht-verwahrenden Handel entwerfen
Die eine, die ich nicht zu brauchen erwartet hatte
Ein Bonus, weil sie mich am meisten überrascht hat: In einer Geldoberfläche braucht das Frontend dieselbe Paranoia wie die Engine.
Ein fokussiertes <input type="number"> verändert seinen Wert schrittweise, wenn Sie mit dem Rad darüber scrollen. Bei einer Mengenauswahl ist das ein Ärgernis. Bei Hebel, Ordergröße und Preis schreibt es still um, was der Nutzer gewählt hat, und das Formular validiert trotzdem. An diesem Bug ist nichts in einem Screenshot sichtbar.
Die ganze Geschichte: das Mausrad bearbeitet Ihre Zahlenfelder
Wenn ich alles in einen Satz pressen müsste
Bauen Sie für die Fehler, die sich nicht ankündigen. Die, die eine Ausnahme werfen, finden Sie von selbst.