Introducción a las órdenes RPI
Una orden Retail Price Improvement (RPI) es un tipo de orden especializado diseñado exclusivamente para market makers aprobados. Solo se empareja con órdenes no algorítmicas colocadas a través de la App o la interfaz Web, ofreciendo a los traders minoristas una liquidez de mercado más específica y mejores precios de ejecución. Al mismo tiempo, protege las órdenes de provisión de liquidez de los market makers para que no se emparejen con órdenes algorítmicas, manteniendo la equidad e integridad general del mercado.
I. ¿Qué es una orden RPI?
Una orden RPI es una orden límite especial que solo pueden enviar a través de OpenAPI los market makers incluidos en la whitelist. Cuenta con cuatro características principales:
•Emparejamiento específico: Se empareja exclusivamente con órdenes no algorítmicas enviadas a través de las interfaces de la App y Web. No se empareja con órdenes API (incluidas otras órdenes RPI) ni con órdenes de grid bot.
• Prioridad más baja: En el mismo nivel de precio, las órdenes RPI solo participarán en el emparejamiento después de que se hayan ejecutado todas las órdenes que no sean RPI.
•Solo maker: Son órdenes límite pasivas que siempre aportan liquidez al libro de órdenes y nunca retiran liquidez.
•Diferencia de visibilidad: Se muestran normalmente en las interfaces de la App y Web; invisibles en el libro de órdenes público de API.
II. ¿Quién puede enviar órdenes RPI?
Las órdenes RPI solo pueden enviarse a través de OpenAPI por market makers aprobados e incluidos en la whitelist, y están estrictamente restringidas a pares de trading incluidos en la whitelist.
• Los envíos realizados por market makers no incluidos en la whitelist activarán el mensaje: “Las órdenes RPI solo están disponibles para market makers aprobados.”
• Los envíos en pares de trading no incluidos en la whitelist activarán el mensaje: “Las órdenes RPI solo son compatibles con pares de trading específicos”.
III. ¿Cómo enviar órdenes RPI?
Las órdenes RPI solo pueden enviarse a través de OpenAPI, y son compatibles tanto con los métodos REST como WebSocket. Al colocar una orden, el tipo de orden (type) debe establecerse como una orden límite (buy-limit o sell-limit), y el campo time-in-force debe establecerse en rpi. Todos los demás parámetros permanecen idénticos a los de las órdenes límite estándar.
Método REST
Los endpoints de colocación de órdenes spot, por lotes y de margen admiten órdenes RPI (el type debe ser buy-limit o sell-limit). Solo añade el campo time-in-force (con el valor rpi) a los parámetros de solicitud existentes:
• Colocación de órdenes spot: POST /v1/order/orders/place
• Colocación de órdenes por lotes: POST /v1/order/batch-orders
• Colocación de órdenes de margen: POST /v1/order/auto/place
Ejemplo de solicitud (orden de compra RPI spot):
{
"account-id": "12345",
"symbol": "btcusdt",
"type": "buy-limit",
"amount": "0.01",
"price": "50000",
"time-in-force": "rpi"
}
Método WebSocket
Los canales de trading de WebSocket también admiten la colocación de órdenes RPI, usando los mismos parámetros que la API REST:
• Colocación de órdenes spot: canal create-order
• Colocación de órdenes por lotes: canal create-batchorder
• Colocación de órdenes de margen: canal create-margin-order
Códigos de error comunes
| Código de error |
Descripción |
|
|
La cuenta actual no está en la whitelist de RPI y no está autorizada para enviar órdenes RPI. |
|
|
Este par de trading no está en la whitelist de RPI y no admite el envío de órdenes RPI. |
|
|
El type debe ser buy-limit o sell-limit. |
|
|
La función RPI está desactivada actualmente. Contacta con el equipo de operaciones para confirmar el calendario de lanzamiento. |
¿Qué pares de trading admiten órdenes RPI?
Llama al endpoint Obtener todos los pares de trading GET /v2/settings/common/symbol. Cada par de trading en la respuesta incluye un campo enable_rpi (booleano). Un valor de true indica que el soporte de RPI está activado para el par de trading, mientras que un valor de false indica que no es compatible.
Ejemplo de respuesta (solo campos clave):
{
"status": "ok",
"data": [
{ "sc": "btcusdt", "dn": "BTC/USDT", "enable_rpi": true },
{ "sc": "ethusdt", "dn": "ETH/USDT", "enable_rpi": false }
]
}
Si se envía una solicitud de orden RPI para un par de trading que no admite RPI, el sistema devolverá el código de error order-rpi-symbol-not-allowed.
IV. Alcance de emparejamiento
Órdenes que pueden emparejarse con órdenes RPI
• Fuente: interfaz App / Web
• Tipos: órdenes de mercado, órdenes límite, límite avanzada-FOK, límite avanzada-IOC, órdenes take-profit/stop-loss, órdenes de mercado/límite activadas por órdenes condicionales
• Especial: Las órdenes de copy trading / follow trading y las órdenes iceberg se tratan como órdenes regulares y pueden emparejarse normalmente.
Órdenes no aptas para emparejamiento RPI
• Todas las órdenes API (incluidas otras órdenes RPI y las órdenes condicionales activadas a través de canales API)
• Órdenes de grid bot
V. Reglas de trading
| Ítem de regla |
Descripción |
| Productos compatibles |
Spot (incluido Margin) |
| Mecanismo de órdenes |
Idéntico al de las órdenes límite estándar (mismos requisitos de margen, tamaños mínimos/máximos de orden y límites de precio) |
| Operaciones compatibles |
Colocación de órdenes por lotes, modificación (precio/cantidad), cancelación, cancelación de órdenes por lotes y ejecución parcial de órdenes |
| Incompatibilidad |
No puede combinarse con órdenes condicionales (TP/SL, orden de activación, etc.) |
| Límite de precio |
Al colocar una orden, esta no puede cruzar el precio de las órdenes no RPI del lado opuesto; de lo contrario, será cancelada. |
Ejemplo de límite de precio
•Enviar una orden de compra RPI a un precio de 99 → Aceptada.
•Enviar una orden de compra RPI a un precio de 102 → Rechazada, ya que cruza la orden no RPI en Ask 2 (precio 102)
| Nivel |
Precio |
Cantidad |
| Ask 2 |
102 |
25 |
| Ask 1 |
100 (RPI) |
15 |
| Bid 1 |
99 (RPI) |
10 |
| Bid 2 |
98 |
20 |
VI. Visibilidad de las órdenes
| Módulo |
Escenario |
Descripción |
| Libro de órdenes |
APP / Web |
Las órdenes RPI se muestran normalmente sin etiquetas especiales; se ocultan automáticamente cuando los precios se cruzan. Las órdenes ocultas permanecen activas en el motor de emparejamiento y pueden ejecutarse cuando se cumplen las condiciones. |
| OpenAPI |
No visible. |
|
| Historial personal de órdenes |
APP / Web |
Los market makers pueden ver las órdenes RPI y la etiqueta “RPI” en los registros de órdenes actuales e históricos; las órdenes de los usuarios regulares no muestran etiquetas especiales. |
| OpenAPI |
Las órdenes RPI se muestran normalmente y pueden distinguirse de las órdenes regulares. |
Ejemplos de ocultación por cruce de precios
Ejemplo 1: Dos órdenes RPI con precios cruzados (precio de compra ≥ precio de venta) → Ambos lados se ocultan.
| / |
Precio |
Cantidad |
Visible |
| Ask 4 |
1.005 |
20 |
Sí |
| Ask 3 |
1.003 (RPI) |
15 |
Sí |
| Ask 2 |
1.001 (RPI) |
10 |
No |
| Ask 1 |
999 (RPI) |
5 |
No |
| Bid 1 |
1.002 (RPI) |
10 |
No |
| Bid 2 |
1.000 (RPI) |
20 |
No |
| Bid 3 |
998 |
25 |
Sí |
| Bid 4 |
997 (RPI) |
30 |
Sí |
Ejemplo 2: Una orden RPI se cruza con una orden API o una orden de estrategia grid → La orden RPI se oculta; la orden de la contraparte se muestra normalmente
| / |
Precio |
Cantidad |
Visible |
| Ask 4 |
1.005 |
20 |
Sí |
| Ask 3 |
1.003 (RPI) |
15 |
Sí |
| Ask 2 |
1.001 (RPI) |
10 |
No |
| Ask 1 |
999 (RPI) |
5 |
No |
| Bid 1 |
1.002 (Bots de Grid) |
10 |
Sí |
| Bid 2 |
1.000 (API) |
20 |
Sí |
| Bid 3 |
998 |
25 |
Sí |
| Bid 4 |
997 (RPI) |
30 |
Sí |
VII. Estructura de comisiones
Las órdenes RPI están sujetas a una tasa de comisión maker RPI exclusiva, que sustituye la tasa de comisión maker original del market maker. Las órdenes no RPI seguirán cobrando la tasa de comisión original.
La tasa de comisión RPI exclusiva puede consultarse a través del endpoint GET /v2/reference/transact-fee-rate. Se añade un nuevo campo rpiFeeRate a los parámetros de respuesta, que representa la tasa de comisión maker RPI efectiva actual. Como alternativa, puedes consultar directamente con el equipo de operaciones de market makers de HTX.
VIII. Actualizaciones de endpoints API y flujos de datos
Para admitir el mecanismo de órdenes RPI, los endpoints existentes se han ajustado de acuerdo con las siguientes reglas.
Datos de mercado REST
| Nombre del endpoint |
Solicitud HTTP |
Descripción de los cambios |
| Profundidad del libro de órdenes |
|
Añade un parámetro opcional includeRpi (booleano, valor predeterminado false). Cuando se establece en true, los datos de profundidad no agregados (step0) incluirán órdenes RPI. Los demás niveles agregados no se verán afectados. |
| Profundidad completa del libro de órdenes |
|
Igual que lo anterior, con la adición del parámetro includeRpi |
| Trades recientes del mercado |
|
La respuesta de cada trade añade un campo isRpiTrade (booleano); true indica que la ejecución fue generada por una orden RPI. |
| Historial de trades recientes |
|
Igual que lo anterior, con la adición del campo isRpiTrade. |
| Últimos tickers de todos los pares de trading |
|
Sin cambios estructurales; las ejecuciones RPI se incluyen normalmente en las métricas. |
| Detalles del ticker fusionado |
|
Sin cambios estructurales; las ejecuciones RPI se incluyen normalmente en las métricas. |
| Detalles del mercado de 24 horas |
|
Sin cambios estructurales; las ejecuciones RPI se incluyen normalmente en las métricas. |
| Datos de velas (K-Line) |
|
Sin cambios estructurales; las ejecuciones RPI se incluyen normalmente en las métricas. |
Flujo de datos de mercado WebSocket
| Canal |
Incluye órdenes RPI |
Descripción |
|
|
No |
Datos tick-by-tick de la mejor oferta/demanda; las órdenes RPI se excluyen de los cálculos. |
|
|
No |
Cotizaciones de profundidad de mercado, las órdenes RPI pendientes no se incluyen en el push |
|
|
Sí (Nuevo) |
Se añade un nuevo canal de push para agregar órdenes RPI pendientes. El protocolo es consistente con el canal de profundidad, lo que permite a los market makers suscribirse de forma independiente a datos de profundidad completos que incluyen RPI. |
|
|
No |
Profundidad MBP incremental; las órdenes RPI no se incluyen en el push. |
|
|
No |
Snapshot MBP completo; las órdenes RPI no se incluyen en el push. |
Endpoints de colocación y consulta de órdenes (REST)
| Nombre del endpoint |
Solicitud HTTP |
Descripción de los cambios |
| Colocar órdenes spot |
|
Añade el campo time-in-force (valor: rpi). |
| Colocar órdenes por lotes |
|
Añade el campo time-in-force (valor: rpi). |
| Colocar orden de margen |
|
Añade el campo time-in-force (valor: rpi). |
| Consultar órdenes abiertas actuales |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). |
| Consultar detalles de la orden |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). Se añade un nuevo valor enum canceled-source, rpi_cancel, que indica que la orden fue cancelada por el sistema debido al cruce de precios con una orden no RPI. |
| Consultar por clientOrderId |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). Se añade un nuevo valor enum canceled-source, rpi_cancel, que indica que la orden fue cancelada por el sistema debido al cruce de precios con una orden no RPI. |
| Detalles de la trade |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). Se añade un nuevo valor enum canceled-source, rpi_cancel, que indica que la orden fue cancelada por el sistema debido al cruce de precios con una orden no RPI. |
| Buscar historial de órdenes |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). Se añade un nuevo valor enum canceled-source, rpi_cancel, que indica que la orden fue cancelada por el sistema debido al cruce de precios con una orden no RPI. |
| Historial de órdenes de las últimas 48 horas |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). Se añade un nuevo valor enum canceled-source, rpi_cancel, que indica que la orden fue cancelada por el sistema debido al cruce de precios con una orden no RPI. |
| Trades actuales e históricas |
|
Se añade un nuevo campo time-in-force a la respuesta (el valor rpi indica una orden RPI). |
Push de órdenes (WebSocket)
| Canal |
Descripción |
Descripción de los cambios |
|
|
Push de actualización de órdenes |
Se añade un nuevo campo time-in-force (valor: rpi), lo que permite diferenciar en tiempo real entre órdenes RPI y órdenes regulares. |
|
|
Actualizaciones de trades posteriores a la liquidación y de cancelación de órdenes |
Se añade un nuevo campo time-in-force (valor: rpi); se añade un nuevo valor enum canceled-source, rpi_cancel, lo que permite identificar en tiempo real las cancelaciones activadas por cruce de precios. |
Con esto concluye la documentación de órdenes RPI.
