Вступ до ордерів RPI
Ордер Retail Price Improvement (RPI) — це спеціалізований тип ордера, призначений виключно для схвалених маркетмейкерів. Він зіставляється лише з неалгоритмічними ордерами, розміщеними через застосунок або вебінтерфейс, забезпечуючи роздрібним трейдерам ліквідність, орієнтовану саме на них, а також вигідніші ціни виконання. Водночас він захищає ордери маркетмейкерів, що забезпечують ліквідність, від зіставлення з алгоритмічними ордерами, підтримуючи загальну справедливість і цілісність ринку.
I. Що таке ордер RPI?
Ордер RPI — це спеціальний лімітний ордер, який маркетмейкери з білого списку можуть подавати лише через OpenAPI. Він має чотири ключові характеристики:
• Вибіркове зіставлення: зіставляється виключно з неалгоритмічними ордерами, поданими через застосунок і вебінтерфейс. Не зіставляється з API-ордерами (включно з іншими RPI-ордерами) або ордерами сіткових ботів.
• Найнижчий пріоритет виконання: за однакової ціни ордери RPI беруть участь у зіставленні лише після виконання всіх ордерів, що не є RPI.
• Лише мейкер: це пасивні лімітні ордери, які завжди додають ліквідність до книги ордерів і ніколи її не забирають.
• Особливості показу: ордери показуються у застосунку та вебінтерфейсі, але не показуються в публічній книзі ордерів API.
II. Хто може подавати ордери RPI?
Ордери RPI можуть подавати лише схвалені маркетмейкери з білого списку через OpenAPI, і лише для торгових пар із білого списку.
• Якщо ордер подає маркетмейкер, якого немає в білому списку, з’явиться повідомлення: "Ордери RPI доступні лише для схвалених маркетмейкерів."
• Якщо ордер подається для торгової пари, якої немає в білому списку, з’явиться повідомлення: "Ордери RPI підтримуються лише для певних торгових пар".
III. Як подати ордер RPI?
Ордери RPI можна подавати виключно через OpenAPI — підтримуються два способи: REST і WebSocket. При розміщенні ордера його тип (type) необхідно встановити як лімітний ордер (buy-limit або sell-limit), а поле time-in-force необхідно встановити на rpi. Усі інші параметри залишаються такими ж, як і у стандартних лімітних ордерах.
Спосіб REST
Усі кінцеві точки розміщення спотових, пакетних та маржинальних ордерів підтримують ордери типу RPI (тип повинен бути buy-limit або sell-limit). Просто додайте поле time-in-force (зі значенням rpi) до наявних параметрів запиту:
• Розміщення спотових ордерів: POST /v1/order/orders/place
• Розміщення груп ордерів: POST /v1/order/batch-orders
• Розміщення маржинальних ордерів: POST /v1/order/auto/place
Приклад запиту (спотовий ордер RPI на купівлю)
{
"account-id": "12345",
"symbol": "btcusdt",
"type": "buy-limit",
"amount": "0.01",
"price": "50000",
"time-in-force": "rpi"
}
Спосіб WebSocket
Торгові канали WebSocket також підтримують розміщення ордерів RPI з використанням тих самих параметрів, що й REST API:
• Розміщення спотових ордерів: канал create-order
• Розміщення груп ордерів: канал create-batchorder
• Розміщення маржинальних ордерів: канал create-margin-order
Поширені коди помилок
| Код помилки |
Значення |
|
|
Цей поточний обліковий запис не входить до білого списку RPI та не має дозволу на подання ордерів RPI. |
|
|
Ця торгова пара не входить до білого списку RPI та не підтримує подачу ордерів RPI. |
|
|
type має бути buy-limit або sell-limit |
|
|
Функція RPI наразі вимкнена. Будь ласка, зверніться до операційної команди, щоб уточнити графік запуску. |
Які торгові пари підтримують ордери RPI?
Викличте кінцеву точку для отримання всіх торгових пар: GET /v2/settings/common/symbol. Кожна торгова пара у відповіді містить поле enable_rpi (boolean). Значення true означає, що підтримка RPI для даної торгової пари увімкнена, тоді як значення false — що вона не підтримується.
Приклад відповіді (лише ключові поля):
{
"status": "ok",
"data": [
{ "sc": "btcusdt", "dn": "BTC/USDT", "enable_rpi": true },
{ "sc": "ethusdt", "dn": "ETH/USDT", "enable_rpi": false }
]
}
Якщо запит на ордер RPI подано для торгової пари, яка не підтримує RPI, система поверне код помилки order-rpi-symbol-not-allowed.
IV. Область зіставлення
Ордери, які можна зіставити із ордерами RPI
• Джерело: додаток / вебінтерфейс
• Типи: ринкові ордери, лімітні ордери, розширені лімітні ордери FOK, розширені лімітні ордери IOC, ордери тейк-профіт/стоп-лос, ринкові/лімітні ордери, що запускаються умовними ордерами
• Особливі: ордери копітрейдингу (провідні/скопійовані) та айсберг-ордери розглядаються як звичайні ордери й можуть зіставлятися у звичайному порядку
Ордери, які не можна зіставити із ордерами RPI
• Усі ордери через API (включно з іншими ордерами RPI та умовними ордерами, що спрацьовують через канали API)
• Ордери сіткових ботів
V. Правила торгівлі
| Пункт правил |
Опис |
| Підтримувані продукти |
Спот (включно з маржею) |
| Механізм ордерів |
Ідентичні стандартним лімітним ордерам (ті самі вимоги до маржі, мінімального/максимального розміру ордерів і цінових лімітів) |
| Підтримувані операції |
Розміщення груп ордерів, внесення змін (ціна/кількість), скасування, скасування груп ордерів і часткове виконання ордерів |
| Несумісність |
Не можна поєднувати з умовними ордерами (TP/SL, тригерні ордери тощо) |
| Ліміт ціни |
При розміщенні ордера його ціна не може перевищувати ціну ордерів, що не є RPI, на протилежному боці; в іншому випадку він буде скасований |
Приклад ліміту ціни
•Розміщення ордера RPI на купівлю за ціною 99→ Прийнято
•Розміщення ордера RPI на купівлю за ціною 102 → Відхилено, оскільки він перетинається із ордером, що не є RPI, на рівні ціни продажу 2 (ціна 102)
| Рівень |
Ціна |
Кількість |
| Ціна продажу 2 |
102 |
25 |
| Ціна продажу 1 |
100 (RPI) |
15 |
| Ціна купівлі 1 |
99 (RPI) |
10 |
| Ціна купівлі 2 |
98 |
20 |
VI. Видимість ордерів
| Модуль |
Сценарій |
Опис |
| Книга ордерів |
Додаток / Вебверсія |
Ордери RPI показуються без спеціальних тегів; вони автоматично приховуються, коли ціни перетинаються. Приховані ордери залишаються активними в механізмі зіставлення і можуть бути виконані, коли будуть виконані відповідні умови. |
| OpenAPI |
Не видимі. |
|
| Історія особистих ордерів |
Додаток / Вебверсія |
Маркетмейкери можуть переглядати ордери з позначкою "RPI" у поточних і записах попередніх ордерів; ордери звичайних користувачів не містять спеціальних позначок. |
| OpenAPI |
Ордери RPI показуються у звичайному режимі, їх можна відрізнити від стандартних ордерів. |
Приклади приховування перетину цін
Приклад 1: два ордери RPI з перетином цін (ціна купівлі ≥ ціна продажу) → обидві сторони приховані.
| / |
Ціна |
Кількість |
Видимість |
| Ціна продажу 4 |
1 005 |
20 |
Так |
| Ціна продажу 3 |
1 003 (RPI) |
15 |
Так |
| Ціна продажу 2 |
1 001 (RPI) |
10 |
Ні |
| Ціна продажу 1 |
999 (RPI) |
5 |
Ні |
| Ціна купівлі 1 |
1 002 (RPI) |
10 |
Ні |
| Ціна купівлі 2 |
1 000 (RPI) |
20 |
Ні |
| Ціна купівлі 3 |
998 |
25 |
Так |
| Ціна купівлі 4 |
997 (RPI) |
30 |
Так |
Приклад 2: ордер RPI перетинається з ордером API або ордером за сітковою стратегією → ордер RPI прихований; ордер контрагента показується як звичайно
| / |
Ціна |
Кількість |
Видимість |
| Ціна продажу 4 |
1 005 |
20 |
Так |
| Ціна продажу 3 |
1 003 (RPI) |
15 |
Так |
| Ціна продажу 2 |
1 001 (RPI) |
10 |
Ні |
| Ціна продажу 1 |
999 (RPI) |
5 |
Ні |
| Ціна купівлі 1 |
1 002 (ордер сіткового бота) |
10 |
Так |
| Ціна купівлі 2 |
1 000 (API) |
20 |
Так |
| Ціна купівлі 3 |
998 |
25 |
Так |
| Ціна купівлі 4 |
997 (RPI) |
30 |
Так |
VII. Структура комісій
На ордери RPI поширюється ексклюзивна ставка комісії RPI для маркетмейкерів, яка замінює початкову ставку комісії маркетмейкера. За ордери, що не є RPI, комісія продовжує стягуватися за початковою ставкою.
Інформацію про ексклюзивну ставку комісії RPI можна отримати через кінцеву точку GET /v2/reference/transact-fee-rate. До параметрів відповіді додано нове поле rpiFeeRate, яке показує поточну дієву ставку комісії для маркетмейкерів RPI. Крім того, ви можете звернутися безпосередньо до команди з операцій маркетмейкерів HTX.
VIII. Оновлення кінцевих точок API та потоків даних
Для забезпечення роботи механізму ордерів RPI наявні кінцеві точки налаштовано відповідно до наступних правил.
Ринкові дані REST
| Назва інтерфейсу |
HTTP-запит |
Опис змін |
| Глибина книги ордерів |
|
Додається необов’язковий параметр includeRpi (Boolean, за замовчуванням false). Якщо встановлено значення true, не агреговані дані глибини (step0) будуть містити ордери RPI. На інші агреговані рівні це не впливає. |
| Повна глибина книги ордерів |
|
Так само, як і вище, але з додаванням параметра includeRpi |
| Останні ринкові угоди |
|
У відповіді на кожну операцію додається поле isRpiTrade (Boolean); значення true вказує на те, що виконання було ініційовано ордером RPI. |
| Історія останніх угод |
|
Так само, як і вище, але з додаванням параметра isRpiTrade |
| Актуальні тікери для всіх торгових пар |
|
Структурних змін немає; виконання RPI враховується в показниках у звичайному порядку. |
| Зведені дані про тікери |
|
Структурних змін немає; виконання RPI враховується в показниках у звичайному порядку. |
| Деталі про ринок за 24 год |
|
Структурних змін немає; виконання RPI враховується в показниках у звичайному порядку. |
| Дані свічок (K-Line) |
|
Структурних змін немає; виконання RPI враховується в показниках у звичайному порядку. |
Потік ринкових даних WebSocket
| Канал |
Включає ордери RPI |
Опис |
|
|
Ні |
Дані про найкращі ціни купівлі/продажу з точністю до кожного тіку; ордери RPI не враховуються при розрахунках. |
|
|
Ні |
Котирування глибини ринку та відкладені ордери RPI не включені в push-повідомлення |
|
|
Так (нові) |
Додає новий push-канал для агрегації відкладених ордерів RPI. Протокол відповідає каналу глибини ринку, що дозволяє маркетмейкерам самостійно підписуватися на повні дані про глибину ринку, включно з RPI. |
|
|
Ні |
Інкрементальна глибина MBP, ордери RPI не включаються в push. |
|
|
Ні |
Повний знімок MBP, ордери RPI не включаються в push. |
Кінцеві точки для розміщення ордерів і запитів (REST)
| Назва інтерфейсу |
HTTP-запит |
Опис змін |
| Розміщення спотових ордерів |
|
Додає поле time-in-force (значення: rpi). |
| Розміщення груп ордерів |
|
Додає поле time-in-force (значення: rpi). |
| Розміщення маржинальних ордерів |
|
Додає поле time-in-force (значення: rpi). |
| Запит поточних відкритих ордерів |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). |
| Запит деталей ордера |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). До canceled-source додано нове значення rpi_cancel, яке вказує, що ордер було скасовано системою через перетин ціни з ордером, який не є RPI. |
| Запит за clientOrderId |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). До canceled-source додано нове значення rpi_cancel, яке вказує, що ордер було скасовано системою через перетин ціни з ордером, який не є RPI. |
| Деталі угоди |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). До canceled-source додано нове значення rpi_cancel, яке вказує, що ордер було скасовано системою через перетин ціни з ордером, який не є RPI. |
| Пошук історії ордерів |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). До canceled-source додано нове значення rpi_cancel, яке вказує, що ордер було скасовано системою через перетин ціни з ордером, який не є RPI. |
| Історія ордерів за останні 48 год |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). До canceled-source додано нове значення rpi_cancel, яке вказує, що ордер було скасовано системою через перетин ціни з ордером, який не є RPI. |
| Поточні та минулі угоди |
|
До відповіді додано нове поле time-in-force (значення rpi вказує на ордер RPI). |
Push-оновлення ордерів (WebSocket)
| Канал |
Опис |
Опис змін |
|
|
Push-оновлення щодо ордерів |
Додано нове поле time-in-force (значення: rpi), яке дає змогу в режимі реального часу розрізняти ордери RPI та звичайні ордери. |
|
|
Оновлення угод і скасувань ордерів після клірингу |
Додано нове поле time-in-force (значення: rpi), а також нове значення rpi_cancel для поля canceled-source, що дає змогу в режимі реального часу визначати скасування, спричинені перетином цін. |
На цьому документація щодо ордеру RPI завершується.
