Лимитный и рыночный ордер задают разные условия исполнения. Рыночная заявка поручает купить или продать по доступным ценам; лимитная ограничивает допустимую цену. Но название заявки ещё не объясняет, сколько актива будет куплено, когда завершится исполнение и что произойдёт с остатком. Для торгового бота эти вопросы особенно важны: следующая команда может появиться раньше, чем предыдущая окончательно обработана.

Проверять нужно цепочку «решение — отправка — подтверждение — сделки — остаток позиции». Ниже — учебный разбор этой цепочки. Все числа условные и служат для проверки арифметики, а не показывают результат какой-либо программы.

Чем отличаются условия заявки

Для покупки лимит задаёт максимальную цену, для продажи — минимальную. Исполнение по более выгодной цене допускается, но наличие лимита не гарантирует сделку. Рыночная заявка не фиксирует цену: последняя цена на графике может отличаться от фактической. Эти определения приведены в памятке Investor.gov о типах заявок.

Не стоит автоматически считать лимитную заявку заявкой maker. Если она сразу встречает подходящие предложения, она может забрать ликвидность. На Coinbase Advanced это описано вместе с частичным исполнением и режимом post-only в документации типов ордеров. Названия дополнительных параметров и доступные режимы зависят от площадки.

Пример: одна команда, две цены исполнения

Представим условный стакан продажи: 3 единицы актива предлагаются по 100 USDT и ещё 4 — по 100,20 USDT. Бот отправляет покупку 5 единиц. Допустим, предложения не изменились, других ограничений нет и заявка исполнилась полностью:

• 3 × 100 = 300 USDT приходится на первое исполнение.

• 2 × 100,20 = 200,40 USDT приходится на второе.

• Общая стоимость равна 500,40 USDT, средняя цена — 100,08 USDT.

По сравнению с условной опорной ценой 100 расходы на покупку выше на 0,40 USDT до комиссий. Это отличие нельзя объяснить только скоростью бота: в самом примере нужного объёма по первой цене не было. В реальности предложения дополнительно меняются между наблюдением и исполнением.

Теперь зададим лимит покупки 100,10 USDT. В том же неизменном стакане подходят только первые 3 единицы. Судьба оставшихся 2 зависит от срока действия и правил обработки остатка. Если выбран режим, который оставляет остаток в книге, он продолжит ожидание; другой режим может его отменить. Отчёт «заявка принята» ещё не означает, что куплены все 5 единиц.

Почему бот должен знать об остатке

Предположим, программа планирует затем продать купленные 5 единиц, но получила только 3. Если она ориентируется на отправленный объём, а не на подтверждённые исполнения, следующая команда окажется несогласованной с позицией. Конкретное последствие зависит от счёта: отказ, использование другого остатка или открытие нежелательной позиции. Корректность проверяется по истории, а не по предполагаемому результату.

В журнале полезно хранить идентификатор заявки, общий исполненный объём, объём последнего исполнения и остаток. Повторное сообщение об уже учтённой сделке не должно увеличивать позицию второй раз. Это критерии проверки программной логики, а не утверждение, что конкретная программа обязательно допускает такую ошибку.

Протокол проверки на тестовом примере

1. Зафиксируйте условия. Укажите инструмент, направление, единицы объёма, тип заявки, лимит и режим остатка. Отдельно сохраните время и опорную цену.

2. Разделите сообщения. Отметьте время отправки, принятия, каждого исполнения и окончательного статуса. Отсутствие ответа само по себе не доказывает отказ.

3. Пересчитайте объём. Сумма уникальных исполнений должна совпасть с исполненным объёмом заявки, а изменения позиции — с учётом других операций.

4. Пересчитайте цену. Разделите сумму «объём × цена» по исполнениям на суммарный объём. Не усредняйте цены без весов.

5. Проверьте отмену. Запрос на отмену и подтверждённая отмена — разные события. Учтите исполнения, которые попали между ними.

6. Сверьте деньги. Сопоставьте стоимость исполнений и комиссии с отчётом площадки. Сохраните валюту каждой комиссии.

Такой протокол можно сначала пройти на подготовленной истории или в доступной тестовой среде. Отдельно запишите случаи, которые она не воспроизводит: очередь заявок, ограничения объёма, задержки или изменение ликвидности. Успешный пример проверяет описанный сценарий, но не доказывает одинаковое поведение при любых рыночных условиях.

Ошибки, которые искажают вывод

• Сравнивать среднюю цену покупки с ценой продажи из другой стороны стакана.

• Считать касание лимита на графике доказательством полного исполнения.

• После тайм-аута повторять заявку, не выяснив статус первой.

• Считать цену срабатывания стопа гарантированной ценой выхода.

Комиссионная роль каждого исполнения разобрана в статье о maker и taker. Если бот переносит условие выхода, дополнительно изучите проверку трейлинг-стопа: перемещение уровня и фактическая сделка — разные этапы.

Для проверки всей цепочки используйте аудит исполнения торгового бота. При обращении в поддержку приложите обезличенный фрагмент журнала, ожидаемый и фактический объём, время с часовым поясом и идентификаторы операций. Ключи API и пароли для такого разбора не нужны.