Запобігання самоторгівлі (STP)
Автоматичний захист від самоторгівлі.
Огляд
Коли вхідна (тейкерська) заявка мала б зіставитися з розміщеною (мейкерською) заявкою того самого гаманця, рушій скасовує обидві заявки замість їх виконання. Це запобігає фіктивній торгівлі (wash trading) і захищає маркетмейкерів від випадкового перетину власних котирувань.
STP завжди активний. Немає жодних налаштувань, можливості відмови або альтернативних режимів.
Поведінка
Стратегія: скасування обох заявок
Коли виявлено самоторгівлю:
- Мейкерська заявка скасовується з причиною
"Self-trade prevention" - Тейкерська заявка відхиляється (якщо не було попередніх виконань) або скасовується (якщо була виконана частково)
Виконання між двома заявками не відбувається.
Зіставлення на рівні гаманця
STP порівнює адреси гаманців, а не ключі агентів. Якщо ви використовуєте авторизацію агентів для підписання заявок кількома ключами, усі заявки під одним торговим гаманцем підпадають під дію STP одна щодо одної.
Часткові виконання зберігаються
Якщо тейкерська заявка виконується проти інших контрагентів до виявлення самоторгівлі, ці виконання зберігаються.
Приклад: у книзі заявок є 5 контрактів, запропонованих Гаманцем B, потім 5 контрактів, запропонованих Гаманцем A. Гаманець A подає заявку на купівлю 10 контрактів:
| Крок | Зіставлення з | Результат |
|---|---|---|
| 1 | Гаманець B (5 контрактів) | Виконання: 5 контрактів виконано |
| 2 | Гаманець A (5 контрактів) | Виявлено самоторгівлю |
Підсумок:
- Гаманець A отримує виконання на 5 контрактів проти Гаманця B
- Мейкерська заявка Гаманця A (5 контрактів) скасовується
- Тейкерська заявка Гаманця A скасовується з
filled_size: 5
Статус заявки
| Сценарій | Статус тейкера | Причина |
|---|---|---|
| Без попередніх виконань | Rejected | "Self-trade prevention" |
| Часткові виконання до самоторгівлі | Canceled | "Self-trade prevention (partial fill kept)" |
Мейкерська заявка завжди отримує статус Canceled з причиною "Self-trade prevention".
Заявки GTC не залишаються в книзі після самоторгівлі
Якщо тейкерська заявка GTC спричиняє спрацювання STP, залишкова кількість не додається до книги заявок, навіть якщо заявка зазвичай залишилася б у книзі. Заявка повністю припиняється.
Сповіщення WebSocket
Скасування/відхилення як тейкерської, так і мейкерської заявки доставляються через канал order_updates. Поле reason вказує, що причиною було STP.
Моніторинг
Події STP збільшують лічильник Prometheus ht_engine_self_trade_prevented_total.
Часті питання
Чи можу я обрати інший режим STP (наприклад, скасування новішої заявки або зменшення обсягу)? Ні. Hypercall використовує виключно скасування обох заявок.
Чи застосовується STP до заявок на перпи? Так. STP застосовується до всіх типів заявок у рушії зіставлення, як для опціонів, так і для перпів.
Чи застосовується STP до угод RFQ? Так. Якщо тейкер і постачальник котирування використовують один гаманець, котирування відхиляється.
Я маркетмейкер, який котирує обидві сторони. Чи скасують мої котирування одне одного? Лише якщо вхідна заявка спричинить їх перетин. Розміщені заявки на протилежних сторонах книги заявок за різними цінами співіснують нормально. STP спрацьовує лише в момент зіставлення.