Skip to main content
Когда вы выставляете ордер, блокчейн присваивает ему идентификатор. Этот идентификатор — источник истины, но узнаёте вы его только после того, как ордер принят. А это проблема, если сделать нужно как раз одно — отменить ордер, подтверждения приёма которого вы так и не увидели. Клиентский идентификатор ордера решает эту задачу. Вы генерируете идентификатор сами, прикрепляете его при отправке и можете работать с ордером по этому значению с момента отправки.

​
Почему это важнее, чем кажется

Представьте отправку, которая завершилась таймаутом. Дошла ли она до блокчейна? Неизвестно. Без клиентского идентификатора остаётся либо запросить недавние ордера и угадывать по рынку, стороне, цене и количеству, либо ничего не делать и надеяться. С идентификатором неопределённость исчезает. Вы отменяете по значению, которое сгенерировали сами. Если ордер существовал, он отменён. Если он не дошёл, отмене нечего отменять. В обоих случаях вы оказываетесь в известном состоянии — а именно это и нужно системе, работающей без человека за экраном. По той же причине становится посильной сверка. В ваших собственных записях ключом служит идентификатор, который назначили вы, поэтому сопоставить вашу картину с блокчейном — это поиск по ключу, а не эвристика.

​
Формат

Идентификатор — это 16-байтовое значение, передаваемое как шестнадцатеричная строка из 32 символов в нижнем регистре с префиксом 0x.
Три правила, которые проверяет протокол:
  • Только нижний регистр. Верхний регистр отклоняется, а не нормализуется.
  • Точная длина. Более короткие и более длинные значения отклоняются.
  • Значение из одних нулей зарезервировано. 0x00000000...0000 — это маркер со значением отсутствует, использовать его как идентификатор нельзя.
Поле необязательное. Ордер без него ведёт себя во всём как обычно — просто отменить его по клиентскому идентификатору не получится, только по идентификатору, назначенному блокчейном.

​
Уникальность

Уникальность действует в пределах субсчёта: сочетания подписывающего адреса и субсчёта под ним. Отсюда два следствия. Разные субсчета одного адреса могут использовать один и тот же идентификатор без конфликта — это удобно, когда независимые стратегии генерируют идентификаторы каждая сама по себе. А внутри одного субсчёта повторное использование идентификатора, занятого активным ордером, — ошибка, а не замена.
Генерируйте идентификаторы случайно, а не последовательно. Счётчик соблазнителен тем, что делает порядок наглядным, но если при перезапуске счётчик потеряется, пойдут коллизии с ещё активными ордерами, а 16 случайных байтов на практике не сталкиваются никогда.

​
Что с ним можно делать

​
Срок жизни

Идентификатор принадлежит ордеру, а не вашей сессии. Он остаётся доступен для запроса после исполнения или отмены ордера — именно это и делает его полезным для сверки постфактум. Повторно использовать его можно, как только помеченный им ордер перестаёт быть активным. На практике смысла в этом мало: новое случайное значение ничего не стоит и снимает любой вопрос о том, к какому ордеру относится историческая запись.

​
Что дальше

Изменение ордеров

Как изменить активный ордер и что происходит с его идентификаторами.

Типы ордеров

К чему можно прикрепить идентификатор.

Разработчикам

Отправка ордеров и обработка неоднозначных ответов в коде.

Упорядочивание транзакций

Почему отмена, отправленная в том же блоке, выполняется раньше агрессивного ордера.