Запобігання самоторгівлі (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 (наприклад, скасування новішої заявки або зменшення обсягу)? Ні. Hypercall використовує виключно скасування обох заявок.
Чи застосовується STP до заявок на перпи? Ні. STP у Hypercall застосовується до заявок, що зіставляються в книзі Hypercall: опціонних і комбінованих заявок. Заявки на перпи зіставляються в книзі заявок Hyperliquid, де діють власні правила самоторгівлі Hyperliquid.
Чи застосовується STP до комбінованих заявок? Так. Зіставлення зупиняється до того, як комбінований або імпліцитний маршрут призвів би до угоди рахунку із самим собою, а виставлена мейкерська заявка скасовується. Випадки «все або нічого» (FOK і атомарна заміна) описано в Experimental Combo API.
Чи застосовується STP до угод RFQ? Так. Якщо тейкер і постачальник котирування використовують той самий гаманець, котирування відхиляється.
Я маркетмейкер і котирую обидві сторони. Чи скасовуватимуть мої котирування одне одне? Лише якщо вхідна заявка спричинить їх перетин. Виставлені заявки на протилежних сторонах книги за різними цінами нормально співіснують. STP спрацьовує лише в момент зіставлення.