Skip to main content
Wenn Sie eine Order absenden, vergibt die Chain eine Order-ID. Diese ID ist maßgeblich, aber Sie erfahren sie erst, nachdem die Order angenommen wurde – ein Problem, wenn genau das, was Sie tun müssen, das Stornieren einer Order ist, deren Annahme Sie nie gesehen haben. Eine Client Order ID löst das. Sie erzeugen die Kennung selbst, geben sie beim Absenden mit und können die Order von dem Moment an über diese Kennung ansprechen, in dem Sie sie abschicken.

​
Warum das wichtiger ist, als es klingt

Angenommen, eine Übermittlung läuft in einen Timeout. Ist sie bei der Chain angekommen? Sie wissen es nicht. Ohne Client Order ID bleibt Ihnen nur, die letzten Orders abzufragen und anhand von Markt, Seite, Preis und Menge zu raten – oder nichts zu tun und zu hoffen. Mit einer Client Order ID verschwindet die Mehrdeutigkeit. Sie stornieren über die Kennung, die Sie erzeugt haben. Existierte die Order, ist sie storniert. Kam sie nie an, findet die Stornierung nichts. In beiden Fällen landen Sie in einem bekannten Zustand – und genau das braucht ein System, das ohne menschliche Aufsicht läuft. Das macht auch den Abgleich beherrschbar. Ihre eigenen Aufzeichnungen laufen über eine Kennung, die Sie selbst vergeben haben, sodass der Vergleich Ihrer Sicht mit der der Chain ein Nachschlagen ist und keine Heuristik.

​
Format

Die Kennung ist ein 16-Byte-Wert, übermittelt als hexadezimale Zeichenkette aus 32 Zeichen in Kleinbuchstaben mit 0x-Präfix.
Drei Regeln setzt das Protokoll durch:
  • Nur Kleinbuchstaben. Hex in Großbuchstaben wird abgelehnt und nicht normalisiert.
  • Exakte Länge. Kürzere oder längere Werte werden abgelehnt.
  • Der Nullwert ist reserviert. 0x00000000...0000 ist der Sentinel-Wert für nicht vorhanden und kann nicht als Kennung verwendet werden.
Das Feld ist optional. Eine Order ohne Kennung verhält sich in jeder Hinsicht normal – sie lässt sich lediglich nicht über die Client Order ID stornieren, sondern nur über die von der Chain vergebene Order-ID.

​
Eindeutigkeit

Eindeutigkeit gilt je Unterkonto: für die Kombination aus signierender Adresse und dem Unterkonto darunter. Daraus folgen zwei Dinge. Verschiedene Unterkonten unter derselben Adresse dürfen dieselbe Kennung ohne Konflikt verwenden – praktisch, wenn unabhängige Strategien laufen, die jeweils eigene IDs erzeugen. Und innerhalb eines Unterkontos ist die Wiederverwendung einer Kennung, die zu einer aktiven Order gehört, ein Fehler und keine Ersetzung.
Erzeugen Sie Kennungen zufällig statt fortlaufend. Ein Zähler ist verlockend, weil er die Reihenfolge sichtbar macht, aber ein Neustart, der den Zähler verliert, erzeugt Kollisionen mit Orders, die noch aktiv sind – und 16 zufällige Bytes kollidieren in der Praxis nie.

​
Was Sie damit tun können

​
Lebensdauer

Die Kennung gehört zur Order, nicht zu Ihrer Session. Sie bleibt abfragbar, nachdem die Order ausgeführt oder storniert wurde – genau das macht sie für den nachträglichen Abgleich nützlich. Wiederverwendbar wird sie, sobald die von ihr bezeichnete Order nicht mehr aktiv ist. In der Praxis gibt es kaum einen Grund dafür – ein frischer Zufallswert kostet nichts und beseitigt jede Frage danach, auf welche Order sich ein historischer Eintrag bezieht.

​
Wie es weitergeht

Orders ändern

Eine aktive Order ändern – und was mit ihren Kennungen geschieht.

Ordertypen

Woran sich eine Kennung anhängen lässt.

Entwickler

Orders absenden und mehrdeutige Antworten im Code behandeln.

Transaktionsreihenfolge

Warum eine im selben Block abgesendete Stornierung vor einer aggressiven Order läuft.