Skip to main content
Lorsque vous soumettez un ordre, la chaîne lui attribue un identifiant d’ordre. Cet identifiant fait autorité, mais vous ne le connaissez qu’après l’acceptation de l’ordre — ce qui pose problème quand ce que vous avez à faire, précisément, c’est annuler un ordre dont vous n’avez jamais vu l’acceptation. L’identifiant client d’ordre résout cela. Vous générez l’identifiant vous-même, vous l’attachez à la soumission, et vous pouvez agir sur l’ordre par cet identifiant dès l’instant où vous l’envoyez.

​
Pourquoi cela compte plus qu’il n’y paraît

Prenez une soumission dont le délai d’attente expire. A-t-elle atteint la chaîne ? Vous n’en savez rien. Sans identifiant client d’ordre, vos options sont d’interroger les ordres récents et de deviner d’après le marché, le sens, le prix et la quantité, ou de ne rien faire et d’espérer. Avec un identifiant, l’ambiguïté disparaît. Vous annulez par l’identifiant que vous avez généré. Si l’ordre existait, il est annulé. S’il n’est jamais arrivé, l’annulation ne trouve rien. Dans les deux cas vous terminez dans un état connu, ce dont un système qui tourne sans humain devant l’écran a réellement besoin. C’est aussi ce qui rend le rapprochement praticable. Vos propres enregistrements sont indexés sur un identifiant que vous avez attribué : confronter votre vue à celle de la chaîne devient une recherche, et non une heuristique.

​
Format

L’identifiant est une valeur de 16 octets, soumise sous forme de chaîne hexadécimale en minuscules de 32 caractères, préfixée par 0x.
Trois règles imposées par le protocole :
  • Minuscules uniquement. L’hexadécimal en majuscules est rejeté, et non normalisé.
  • Longueur exacte. Les valeurs plus courtes ou plus longues sont rejetées.
  • La valeur entièrement nulle est réservée. 0x00000000...0000 est la sentinelle qui signifie absent et ne peut pas servir d’identifiant.
Le champ est facultatif. Un ordre qui n’en porte pas se comporte normalement à tous égards — il ne peut simplement pas être annulé par identifiant client d’ordre, seulement par l’identifiant d’ordre attribué par la chaîne.

​
Unicité

L’unicité a pour portée le sous-compte : la combinaison de l’adresse signataire et du sous-compte qui en dépend. Deux conséquences en découlent. Des sous-comptes différents sous une même adresse peuvent utiliser le même identifiant sans conflit — pratique lorsque vous faites tourner des stratégies indépendantes qui génèrent chacune leurs identifiants. Et à l’intérieur d’un même sous-compte, réutiliser un identifiant attaché à un ordre encore actif est une erreur, pas un remplacement.
Générez les identifiants aléatoirement plutôt que séquentiellement. Un compteur est tentant parce qu’il rend la séquence lisible, mais un redémarrage qui perd le compteur produit des collisions avec des ordres encore actifs, alors que 16 octets aléatoires n’entrent jamais en collision en pratique.

​
Ce que vous pouvez en faire

​
Durée de vie

L’identifiant appartient à l’ordre, pas à votre session. Il reste interrogeable après l’exécution ou l’annulation de l’ordre, et c’est ce qui le rend utile pour le rapprochement a posteriori. Il redevient réutilisable dès que l’ordre qu’il désignait n’est plus actif. En pratique, il y a peu de raisons de le réutiliser — une nouvelle valeur aléatoire ne coûte rien et supprime toute question sur l’ordre auquel se rapporte un enregistrement historique.

​
Pour aller plus loin

Modifier un ordre

Modifier un ordre actif, et ce qu’il advient de ses identifiants.

Types d’ordres

Ce à quoi vous pouvez attacher un identifiant.

Développeurs

Soumettre des ordres et traiter les réponses ambiguës dans le code.

Séquencement des transactions

Pourquoi une annulation soumise dans le même bloc s’exécute avant un ordre agressif.