Introduction aux ordres RPI
Un ordre d'Amélioration des prix pour les particuliers (Retail Price Improvement, RPI) est un type d'ordre spécialisé conçu exclusivement pour les market makers approuvés. Il s'apparie uniquement avec des ordres non algorithmiques placés via l'interface de l'application ou du Web, offrant aux traders particuliers une liquidité de marché plus ciblée et de meilleurs prix d'exécution. Parallèlement, il protège les ordres de fourniture de liquidité des market makers contre l'appariement avec des ordres algorithmiques, préservant ainsi l'équité et l'intégrité globales du marché.
I. Qu'est-ce qu'un ordre RPI ?
Un ordre RPI est un ordre limite spécial qui ne peut être soumis que via OpenAPI par les market makers figurant sur liste blanche. Il présente quatre caractéristiques principales :
• Appariement ciblé : S'apparie exclusivement avec des ordres non algorithmiques soumis via les interfaces de l'application et du Web. Il ne s'apparie pas avec les ordres API (y compris les autres ordres RPI) ni avec les ordres des bots de grille.
• Priorité la plus basse : Au même niveau de prix, les ordres RPI ne participent à l'appariement qu'après l'exécution de tous les ordres non RPI.
• Exclusivement maker : Il s'agit d'ordres limites passifs qui fournissent toujours de la liquidité au carnet d'ordres, sans jamais en prendre.
• Différence de visibilité : Affichés normalement sur les interfaces de l'application et du Web ; invisibles dans le carnet d'ordres de l'API publique.
II. Qui peut soumettre des ordres RPI ?
Les ordres RPI ne peuvent être soumis que via OpenAPI par les market makers approuvés figurant sur liste blanche, et sont strictement limités aux paires de trading sur liste blanche.
• Les soumissions par des market makers non listés déclencheront le message : « Les ordres RPI sont réservés aux market makers approuvés. »
• Les soumissions sur des paires de trading non listées déclencheront le message : « Les ordres RPI sont pris en charge uniquement pour des paires de trading spécifiques. »
III. Comment soumettre des ordres RPI ?
Les ordres RPI ne peuvent être soumis que via OpenAPI, en utilisant les méthodes REST et WebSocket. Lors du placement d'un ordre, le type d'ordre (type) doit être défini comme un ordre limite (buy-limit ou sell-limit), et le champ de durée de validité doit être défini sur rpi. Tous les autres paramètres restent identiques à ceux des ordres limites standard.
Méthode REST
Les points de terminaison de placement d'ordres Spot, par lot et sur marge prennent tous en charge les ordres RPI (le type doit être buy-limit ou sell-limit). Il suffit d'ajouter le champ time-in-force (avec la valeur rpi) aux paramètres de requête existants :
• Placement d'ordre Spot : POST /v1/order/orders/place
• Placement d'ordre par lot : POST /v1/order/batch-orders
• Placement d'ordre sur marge : POST /v1/order/auto/place
Exemple de requête (ordre d'achat RPI Spot) :
{
"account-id": "12345",
"symbol": "btcusdt",
"type": "buy-limit",
"amount": "0.01",
"price": "50000",
"time-in-force": "rpi"
}
Méthode WebSocket
Les canaux de trading WebSocket prennent également en charge le placement d'ordres RPI, en utilisant les mêmes paramètres que l'API REST :
• Placement d'ordre Spot : Canal create-order
• Placement d'ordre par lot : Canal create-batchorder
• Placement d'ordre sur marge : Canal create-margin-order
Codes d'erreur courants
| Code d'erreur |
Description |
|
|
Le compte actuel ne figure pas sur la liste blanche RPI et n'est pas autorisé à soumettre des ordres RPI. |
|
|
Cette paire de trading ne figure pas sur la liste blanche RPI et ne prend pas en charge la soumission d'ordres RPI. |
|
|
Le type doit être buy-limit ou sell-limit. |
|
|
La fonctionnalité RPI est actuellement désactivée. Veuillez contacter l'équipe opérationnelle pour confirmer le calendrier de lancement. |
Quelles paires de trading prennent en charge les ordres RPI ?
Appeler le point de terminaison Obtenir toutes les paires de trading GET /v2/settings/common/symbol. Chaque paire de trading dans la réponse inclut un champ enable_rpi (booléen). Une valeur true indique que la prise en charge RPI est activée pour la paire de trading, tandis qu'une valeur false indique qu'elle n'est pas prise en charge.
Exemple de réponse (champs clés uniquement) :
{
"status": "ok",
"data": [
{ "sc": "btcusdt", "dn": "BTC/USDT", "enable_rpi": true },
{ "sc": "ethusdt", "dn": "ETH/USDT", "enable_rpi": false }
]
}
Si une requête d'ordre RPI est soumise pour une paire de trading qui ne prend pas en charge RPI, le système renverra le code d'erreur order-rpi-symbol-not-allowed.
IV. Périmètre d'appariement
Ordres pouvant être appariés avec des ordres RPI
• Source : Interface APP / Web
• Types : Ordres au marché, ordres limite, ordres avancés limite-FOK, ordres avancés limite-IOC, ordres take-profit/stop-loss, ordres au marché/limite déclenchés par des ordres conditionnels
• Spécial : Les ordres de copy trading / trading suiveur et les ordres iceberg sont traités comme des ordres réguliers et peuvent être appariés normalement
Ordres non éligibles à l'appariement RPI
• Tous les ordres API (y compris les autres ordres RPI et les ordres conditionnels déclenchés via les canaux API)
• Ordres des bots de grille
V. Règles de trading
| Élément de règle |
Description |
| Produits pris en charge |
Spot (y compris Marge) |
| Mécanisme d'ordre |
Identique aux ordres limites standard (mêmes exigences de marge, tailles d'ordre minimum/maximum et limites de prix) |
| Opérations prises en charge |
Placement d'ordres par lot, modification (prix/quantité), annulation, annulation d'ordres par lot et exécution partielle d'ordres |
| Incompatibilité |
Ne peut pas être combiné avec des ordres conditionnels (TP/SL, ordre conditionnel, etc.) |
| Limite de prix |
Lors du placement, les ordres ne peuvent pas croiser le prix des ordres non RPI du côté opposé ; sinon, ils seront annulés |
Exemple de limite de prix
•Soumettre un ordre d'achat RPI au prix de 99 → Accepté.
•Soumettre un ordre d'achat RPI au prix de 102 → Rejeté, car il croise l'ordre non RPI au Ask 2 (prix 102)
| Niveau |
Prix |
Quantité |
| Ask 2 |
102 |
25 |
| Ask 1 |
100 (RPI) |
15 |
| Bid 1 |
99 (RPI) |
10 |
| Bid 2 |
98 |
20 |
VI. Visibilité des ordres
| Module |
Scénario |
Description |
| Carnet d'ordres |
APP / Web |
Les ordres RPI sont affichés normalement sans étiquette spéciale ; automatiquement masqués lorsque les prix se croisent. Les ordres masqués restent actifs dans le moteur d'appariement et peuvent être exécutés lorsque les conditions sont remplies. |
| OpenAPI |
Non visible. |
|
| Historique des ordres personnels |
APP / Web |
Les market makers peuvent voir les ordres RPI et l'étiquette « RPI » dans les enregistrements d'ordres actuels et historiques ; les ordres des utilisateurs réguliers ne montrent aucune étiquette spéciale. |
| OpenAPI |
Les ordres RPI sont affichés normalement et peuvent être distingués des ordres réguliers. |
Exemples de masquage par croisement de prix
Exemple 1 : Deux ordres RPI avec des prix croisés (prix d'achat ≥ prix de vente) → Les deux côtés sont masqués.
| / |
Prix |
Quantité |
Visible |
| Ask 4 |
1 005 |
20 |
Oui |
| Ask 3 |
1 003 (RPI) |
15 |
Oui |
| Ask 2 |
1 001 (RPI) |
10 |
Non |
| Ask 1 |
999 (RPI) |
5 |
Non |
| Bid 1 |
1 002 (RPI) |
10 |
Non |
| Bid 2 |
1 000 (RPI) |
20 |
Non |
| Bid 3 |
998 |
25 |
Oui |
| Bid 4 |
997 (RPI) |
30 |
Oui |
Exemple 2 : Un ordre RPI croise un ordre API ou un ordre de stratégie de grille → L'ordre RPI est masqué ; l'ordre de la contrepartie est affiché normalement
| / |
Prix |
Quantité |
Visible |
| Ask 4 |
1 005 |
20 |
Oui |
| Ask 3 |
1 003 (RPI) |
15 |
Oui |
| Ask 2 |
1 001 (RPI) |
10 |
Non |
| Ask 1 |
999 (RPI) |
5 |
Non |
| Bid 1 |
1 002 (Bots de grille) |
10 |
Oui |
| Bid 2 |
1 000 (API) |
20 |
Oui |
| Bid 3 |
998 |
25 |
Oui |
| Bid 4 |
997 (RPI) |
30 |
Oui |
VII. Structure des frais
Les ordres RPI sont soumis à un taux de frais maker RPI exclusif, qui remplace le taux de frais maker d'origine du market maker. Les ordres non RPI continuent d'être facturés au taux de frais d'origine.
Le taux de frais RPI exclusif peut être consulté via le point de terminaison GET /v2/reference/transact-fee-rate. Un nouveau champ rpiFeeRate est ajouté aux paramètres de réponse, représentant le taux de frais maker RPI effectif actuel. Vous pouvez également consulter directement l'équipe des opérations Market Maker de HTX.
VIII. Mises à jour des points de terminaison API et des flux de données
Pour prendre en charge le mécanisme d'ordres RPI, les points de terminaison existants ont été ajustés selon les règles suivantes.
Données de marché REST
| Nom du point de terminaison |
Requête HTTP |
Description des modifications |
| Profondeur du carnet d'ordres |
|
Ajoute un paramètre facultatif includeRpi (Booléen, par défaut false). Lorsqu'il est défini sur true, les données de profondeur non agrégées (step0) incluront les ordres RPI. Les autres niveaux agrégés restent inchangés. |
| Profondeur complète du carnet d'ordres |
|
Identique à ci-dessus, avec l'ajout du paramètre includeRpi |
| Transactions récentes du marché |
|
La réponse pour chaque transaction ajoute un champ isRpiTrade (Booléen) ; true indique que l'exécution a été générée par un ordre RPI. |
| Historique des transactions récentes |
|
Identique à ci-dessus, avec l'ajout du champ isRpiTrade |
| Derniers tickers pour toutes les paires de trading |
|
Aucun changement structurel ; les exécutions RPI sont prises en compte dans les métriques normalement. |
| Détails du ticker fusionné |
|
Aucun changement structurel ; les exécutions RPI sont prises en compte dans les métriques normalement. |
| Détails du marché sur 24 heures |
|
Aucun changement structurel ; les exécutions RPI sont prises en compte dans les métriques normalement. |
| Données en chandeliers (K-line) |
|
Aucun changement structurel ; les exécutions RPI sont prises en compte dans les métriques normalement. |
Flux de données de marché WebSocket
| Canal |
Inclut les ordres RPI |
Description |
|
|
Non |
Données tick par tick de la meilleure offre/demande ; les ordres RPI sont exclus des calculs. |
|
|
Non |
Cotations de profondeur de marché, les ordres RPI en attente ne sont pas inclus dans la diffusion |
|
|
Oui (Nouveau) |
Ajoute un nouveau canal de diffusion pour agréger les ordres RPI en attente. Le protocole est cohérent avec le canal de profondeur, permettant aux market makers de s'abonner indépendamment aux données de profondeur complètes incluant les RPI. |
|
|
Non |
Profondeur MBP incrémentielle ; les ordres RPI ne sont pas inclus dans la diffusion. |
|
|
Non |
Instantané MBP complet ; les ordres RPI ne sont pas inclus dans la diffusion. |
Points de terminaison de placement et de consultation d'ordres (REST)
| Nom du point de terminaison |
Requête HTTP |
Description des modifications |
| Placer des ordres Spot |
|
Ajoute le champ time-in-force (valeur : rpi). |
| Placer des ordres par lot |
|
Ajoute le champ time-in-force (valeur : rpi). |
| Placer un ordre sur marge |
|
Ajoute le champ time-in-force (valeur : rpi). |
| Consulter les ordres ouverts actuels |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). |
| Consulter les détails d'un ordre |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). Une nouvelle valeur d'énumération canceled-source rpi_cancel est ajoutée, indiquant que l'ordre a été annulé par le système en raison d'un croisement de prix avec un ordre non RPI. |
| Recherche par clientOrderId |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). Une nouvelle valeur d'énumération canceled-source rpi_cancel est ajoutée, indiquant que l'ordre a été annulé par le système en raison d'un croisement de prix avec un ordre non RPI. |
| Détails des transactions |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). Une nouvelle valeur d'énumération canceled-source rpi_cancel est ajoutée, indiquant que l'ordre a été annulé par le système en raison d'un croisement de prix avec un ordre non RPI. |
| Rechercher dans l'historique des ordres |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). Une nouvelle valeur d'énumération canceled-source rpi_cancel est ajoutée, indiquant que l'ordre a été annulé par le système en raison d'un croisement de prix avec un ordre non RPI. |
| Historique des ordres des dernières 48 heures |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). Une nouvelle valeur d'énumération canceled-source rpi_cancel est ajoutée, indiquant que l'ordre a été annulé par le système en raison d'un croisement de prix avec un ordre non RPI. |
| Transactions actuelles et historiques |
|
Un nouveau champ time-in-force est ajouté à la réponse (la valeur rpi indique un ordre RPI). |
Push d'ordres (WebSocket)
| Canal |
Description |
Description des modifications |
|
|
Push de mise à jour d'ordre |
Un nouveau champ time-in-force est ajouté (valeur : rpi), permettant de différencier en temps réel les ordres RPI des ordres réguliers. |
|
|
Mises à jour des transactions post-compensation et des annulations d'ordres |
Un nouveau champ time-in-force est ajouté (valeur : rpi) ; une nouvelle valeur d'énumération canceled-source rpi_cancel est ajoutée, permettant d'identifier en temps réel les annulations déclenchées par un croisement de prix. |
Ceci conclut la documentation relative aux ordres RPI.
