Ich habe heute etwas Zeit damit verbracht, den GRVT-Fill-Stream separat vom breiteren Order-State-Stream zu betrachten, weil Fills Informationen tragen, die der Order-Status allein nicht vollständig abbildet.
Ein Update des Order-Status sagt dir zum Beispiel, dass eine Order jetzt teilweise gefüllt wurde. Ein Fill-Event hingegen sagt dir spezifisch etwas über die tatsächliche Ausführung selbst: Preis, Größe und vermutlich auch eine Gebühr, die für genau diesen Fill berechnet wurde.
Diese Informationen hängen zusammen, sind aber unterschiedlich: Der Order-Status bezieht sich auf den allgemeinen Status der Orders; Fill-Events beziehen sich auf jede einzelne Ausführung, die zu diesem Status beiträgt.
Warum würde GRVT diese als separate Streams bereitstellen, statt die Fill-Details einfach in die Order-State-Updates einzufalten.
Mein Eindruck ist, dass eine einzelne Order im Laufe der Zeit mehrere Fills erzeugen kann, wenn sie teilweise über mehrere getrennte Matches ausgeführt wird. Wenn man jeden Fill als eigenes, diskretes Event behandelt, kann ein Client die Ausführungshistorie genau rekonstruieren: durchschnittlicher Fill-Preis, Gebührenaufsummierung – ohne die Historie aus einer Reihe von Order-State-Snapshots ableiten zu müssen.
Für alle, die eine präzise Buchhaltung oder Performance-Analyse machen, ist der Fill-Stream wahrscheinlich die eigentliche Quelle der Wahrheit. Der Order-Status sagt dir, wo die Dinge gerade stehen; die Fills sagen dir ganz genau, wie du dorthin gekommen bist.
Ich arbeite noch daran, herauszufinden, ob ein einzelnes Fill-Event mehrere Orders umfassen kann, im Fall komplexer Order-Typen, oder ob Fills immer sauber eins-zu-eins auf eine einzelne originierende Order bei GRVT abgebildet werden.
$EVAA $LAB $ALLO #ShareYourThoughts @grvt_io #grvt