> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Клиентский идентификатор ордера
> Как привязать к ордеру собственный идентификатор, чтобы отменять и сверять по своему значению, а не по тому, что назначил блокчейн.
Когда вы выставляете ордер, блокчейн присваивает ему идентификатор. Этот идентификатор — источник истины, но узнаёте вы его только *после* того, как ордер принят. А это проблема, если сделать нужно как раз одно — отменить ордер, подтверждения приёма которого вы так и не увидели.
Клиентский идентификатор ордера решает эту задачу. Вы генерируете идентификатор сами, прикрепляете его при отправке и можете работать с ордером по этому значению с момента отправки.
Почему это важнее, чем кажется
Представьте отправку, которая завершилась таймаутом. Дошла ли она до блокчейна? Неизвестно. Без клиентского идентификатора остаётся либо запросить недавние ордера и угадывать по рынку, стороне, цене и количеству, либо ничего не делать и надеяться.
С идентификатором неопределённость исчезает. Вы отменяете по значению, которое сгенерировали сами. Если ордер существовал, он отменён. Если он не дошёл, отмене нечего отменять. В обоих случаях вы оказываетесь в известном состоянии — а именно это и нужно системе, работающей без человека за экраном.
По той же причине становится посильной сверка. В ваших собственных записях ключом служит идентификатор, который назначили вы, поэтому сопоставить вашу картину с блокчейном — это поиск по ключу, а не эвристика.
Идентификатор — это **16-байтовое значение**, передаваемое как шестнадцатеричная строка из 32 символов в нижнем регистре с префиксом `0x`.
```
0xa1b2c3d4e5f6789012345678901234ab
```
Три правила, которые проверяет протокол:
* **Только нижний регистр.** Верхний регистр отклоняется, а не нормализуется.
* **Точная длина.** Более короткие и более длинные значения отклоняются.
* **Значение из одних нулей зарезервировано.** `0x00000000...0000` — это маркер со значением *отсутствует*, использовать его как идентификатор нельзя.
Поле необязательное. Ордер без него ведёт себя во всём как обычно — просто отменить его по клиентскому идентификатору не получится, только по идентификатору, назначенному блокчейном.
Уникальность
Уникальность действует в пределах **субсчёта**: сочетания подписывающего адреса и субсчёта под ним.
Отсюда два следствия. Разные субсчета одного адреса могут использовать один и тот же идентификатор без конфликта — это удобно, когда независимые стратегии генерируют идентификаторы каждая сама по себе. А внутри одного субсчёта повторное использование идентификатора, занятого активным ордером, — ошибка, а не замена.
Генерируйте идентификаторы случайно, а не последовательно. Счётчик соблазнителен тем, что делает порядок наглядным, но если при перезапуске счётчик потеряется, пойдут коллизии с ещё активными ордерами, а 16 случайных байтов на практике не сталкиваются никогда.
Что с ним можно делать
| Операция | Поведение |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Отмена по клиентскому идентификатору** | Отменяет активный ордер с этим идентификатором, без обращения к идентификатору, назначенному блокчейном |
| **Поиск по клиентскому идентификатору** | Возвращает текущее состояние ордера и его историю |
| **Сверка** | Сопоставление ваших записей с записями блокчейна по идентификатору, который назначили вы |
Срок жизни
Идентификатор принадлежит ордеру, а не вашей сессии. Он остаётся доступен для запроса после исполнения или отмены ордера — именно это и делает его полезным для сверки постфактум.
Повторно использовать его можно, как только помеченный им ордер перестаёт быть активным. На практике смысла в этом мало: новое случайное значение ничего не стоит и снимает любой вопрос о том, к какому ордеру относится историческая запись.
Что дальше
Как изменить активный ордер и что происходит с его идентификаторами.
К чему можно прикрепить идентификатор.
Отправка ордеров и обработка неоднозначных ответов в коде.
Почему отмена, отправленная в том же блоке, выполняется раньше агрессивного ордера.