Introduzione Ordine RPI
Un ordine di miglioramento del prezzo al dettaglio (RPI) è una tipologia di ordine specializzata, progettata esclusivamente per i market maker autorizzati. Corrisponde solo a ordini non algoritmici inseriti tramite l'app o l'interfaccia web, fornendo così ai trader al dettaglio una liquidità di mercato più mirata e prezzi di esecuzione migliori. Allo stesso tempo, protegge gli ordini di liquidità dei market maker dall'essere abbinati a ordini algoritmici, preservando l'equità e l'integrità complessiva del mercato.
I. Cosa è un ordine RPI?
Un ordine RPI è un ordine limite speciale che può essere inviato tramite OpenAPI solo dai market maker autorizzati. Presenta quattro caratteristiche principali:
•Matching mirato: Corrisponde esclusivamente agli ordini non algoritmici inviati tramite l'app e l'interfaccia web. Non corrisponde agli ordini API (inclusi altri ordini RPI) o agli ordini del bot della griglia.
• Priorità bassissima: Allo stesso livello di prezzo, gli ordini RPI parteciperanno all'abbinamento solo dopo che tutti gli ordini non-RPI saranno stati eseguiti.
•Solamente Maker: Si tratta di ordini limite passivi che forniscono sempre liquidità al book degli ordini, senza mai prelevare liquidità.
•Differenza di visibilità: Visualizzato normalmente nelle interfacce dell'app e del web; invisibile nel registro ordini pubblico dell'API.
II. Chi può effettuare ordini RPI?
Gli ordini RPI possono essere inviati tramite OpenAPI solo da market maker approvati e inseriti nella whitelist e sono strettamente limitati alle coppie di trading inserite nella whitelist.
• Gli ordini inviati da market maker non inclusi nella lista bianca attiveranno il messaggio: "Gli ordini RPI sono disponibili solo per i market maker approvati."
• L'invio di ordini su coppie di trading non incluse nella lista bianca genererà il messaggio: "Gli ordini RPI sono supportati solo per specifiche coppie di trading."
III. Come inviare ordini RPI?
Gli ordini RPI possono essere inviati solo tramite OpenAPI, che supporta sia i metodi REST che WebSocket. Quando si effettua un ordine, il tipo di ordine (type) deve essere impostato come ordine limite (buy-limit o sell-limit) e il campo time-in-force deve essere impostato su rpi. Tutti gli altri parametri rimangono identici a quelli degli ordini limite standard.
Metodo REST
Gli endpoint per l'inserimento di ordini spot, batch e a margine supportano tutti gli ordini RPI (il tipo deve essere buy-limit o sell-limit). Basta quindi aggiungere il campo time-in-force (con il valore rpi) ai parametri di richiesta esistenti:
• Piazzamento Ordine spot: POST /v1/order/orders/place
• Piazzamento ordine in batch: POST /v1/order/batch-orders
• Piazzamento Ordine margin: POST /v1/order/auto/place
Esempio Richiesta (Ordine acquisto spot RPI):
{
"account-id": "12345",
"symbol": "btcusdt",
"type": "buy-limit",
"amount": "0.01",
"price": "50000",
"time-in-force": "rpi"
}
Metodo WebSocket
I canali di trading WebSocket supportano anche l'inserimento di ordini RPI, utilizzando gli stessi parametri dell'API REST:
Piazzamento Ordine spot: canale create-order
Piazzamento Ordine in batch: canale create-batchorder
Piazzamento Ordine margin: canale create-margin-order
Errori di codice comuni
| Codice Errore |
Descrizione |
|
|
L'account corrente non è nella whitelist RPI e non è autorizzato a inviare ordini RPI |
|
|
La coppia di trading non è nella whitelist RPI e non supporta l'invio di ordini RPI |
|
|
Il tipo deve essere buy-limit o sell-limit. |
|
|
La funzionalità RPI è attualmente disabilitata. Ti preghiamo di contattare il team operativo per confermare la data di lancio. |
Quali coppie di valute supportano gli ordini RPI?
Chiama l'endpoint Get All Trading Pairs GET /v2/settings/common/symbol. Ogni coppia di trading nella risposta include un campo enable_rpi (boolean). Un valore "true" indica che il supporto per l'indice RPI è abilitato per la coppia di trading, mentre un valore "false" indica che non è supportato.
Esempio di risposta (solo campi chiave):
{
"status": "ok",
"data": [
{ "sc": "btcusdt", "dn": "BTC/USDT", "enable_rpi": true },
{ "sc": "ethusdt", "dn": "ETH/USDT", "enable_rpi": false }
]
}
Se viene inviata una richiesta di ordine RPI per una coppia di valute che non supporta RPI, il sistema restituirà il codice di errore order-rpi-symbol-not-allowed.
IV. Scopo Matching
Ordini che possono essere abbinati agli ordini RPI
• Origine: APP / interfaccia Web
• Tipo: ordini mercato, ordini limite, ordini limite avanzati FOK, ordini limite avanzati IOC, ordini take-profit/stop-loss, ordini a mercato/limite attivati da ordini condizionali
• Speciale: Copy trading / ordini di trading successivi e gli ordini iceberg vengono trattati come ordini normali e possono essere abbinati normalmente
Ordini non idonei all'abbinamento RPI
• Tutti gli ordini API (inclusi altri ordini RPI e ordini condizionali attivati tramite canali API)
• Ordini grid bot
V. Regole Trading
| Elemento regola |
Descrizione |
| Prodotti Supportati |
Spot (incluso Margin) |
| Meccanismo ordine |
Identico agli ordini limite standard (stessi requisiti di margine, dimensioni minime/massime dell'ordine e limiti di prezzo) |
| Operazioni supportate |
Inserimento, modifica (prezzo/quantità), annullamento, cancellazione di ordini in blocco ed esecuzione parziale degli ordini |
| Incompatibilità |
Non cumulabile con ordini condizionali (TP/SL, ordine trigger ecc.) |
| Limite prezzo |
Al momento dell'inserimento dell'ordine, gli ordini non possono incrociare il prezzo degli ordini non RPI sul lato opposto; altrimenti, verranno annullati. |
Esempio limite prezzo
•Invio di un ordine di acquisto RPI al prezzo di 99 → Accettato.
•Invio di un ordine di acquisto RPI al prezzo di 102 → Rifiutato, poiché incrocia l'ordine non-RPI al prezzo Ask 2 (prezzo 102)
| Livello |
Prezzo |
Quantità |
| Ask 2 |
102 |
25 |
| Ask 1 |
100 (RPI) |
15 |
| Bid 1 |
99 (RPI) |
10 |
| Bid 2 |
98 |
20 |
VI. Visibilità ordine
| Modulo |
Scenario |
Descrizione |
| Libro ordini |
APP / Web |
Gli ordini RPI vengono visualizzati normalmente senza tag speciali; nascosto automaticamente quando i prezzi si incrociano. Gli ordini nascosti rimangono attivi nel motore di matching e possono essere eseguiti quando vengono soddisfatte le condizioni. |
| OpenAPI |
Non visibile. |
|
| Storico personale ordini |
APP / Web |
Gli operatori di mercato possono visualizzare gli ordini RPI e il tag "RPI" nei registri degli ordini attuali e storici; Gli ordini degli utenti regolari non mostrano tag speciali. |
| OpenAPI |
Gli ordini RPI vengono visualizzati normalmente e si distinguono dagli ordini regolari. |
Esempi di prezzo incrociato nascosto
Esempio 1: Due ordini RPI con prezzi incrociati (prezzo di acquisto ≥ prezzo di vendita) → Entrambi i lati sono nascosti.
| / |
Prezzo |
Quantità |
Visibile |
| 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ì |
Esempio 2: L'ordine RPI si incrocia con un ordine API o un ordine di strategia a griglia → l'ordine RPI è nascosto; l'ordine della controparte viene visualizzato normalmente
| / |
Prezzo |
Quantità |
Visibile |
| 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 (Bot Grid) |
10 |
Sì |
| Bid 2 |
1.000 (API) |
20 |
Sì |
| Bid 3 |
998 |
25 |
Sì |
| Bid 4 |
997 (RPI) |
30 |
Sì |
VII. Struttura Commissioni
Gli ordini RPI sono soggetti a una commissione esclusiva per gli ordini RPI, che sostituisce la commissione originale del market maker. Gli ordini non RPI continuano a essere soggetti alla commissione originale.
Si può valutare l'aliquota esclusiva della commissione RPI tramite l'endpoint GET /v2/reference/transact-fee-rate. Un nuovo campo rpiFeeRate viene aggiunto ai parametri di risposta, rappresentando l'attuale aliquota effettiva della commissione RPI per i market maker. In alternativa, è possibile contattare direttamente il team HTX Market Maker Operations.
VIII. Aggiornamenti endpoint API e flussi dati
Per supportare il meccanismo di ordinazione RPI, gli endpoint esistenti sono stati modificati secondo le seguenti regole.
Dati di mercato REST
| Nome endpoint |
Richiesta HTTP |
Descrizione modifica |
| Profondità Libro ordini |
|
Aggiunge un parametro opzionale includeRpi (booleano, predefinito false). Se impostato su true, i dati di profondità non aggregati (step0) includeranno gli ordini RPI. Gli altri livelli aggregati rimangono invariati. |
| Profondità piena libro ordini |
|
Come sopra, con l'aggiunta del parametro includeRpi |
| Trading mercato recente |
|
La risposta per ogni transazione aggiunge un campo isRpiTrade (Boolean); Il valore "true" indica che l'esecuzione è stata generata da un ordine RPI. |
| Storico trading recente |
|
Come sopra, in aggiunta al campo isRpiTrade |
| Ultimi Ticker di tutte le coppie di trading |
|
Nessuna modifica strutturale; Le esecuzioni RPI sono normalmente incluse nelle metriche. |
| Dettagli unione ticker |
|
Nessuna modifica strutturale; Le esecuzioni RPI sono normalmente incluse nelle metriche. |
| Dettagli mercato 24 ore |
|
Nessuna modifica strutturale; Le esecuzioni RPI sono normalmente incluse nelle metriche. |
| Dati grafico a candela (k-line) |
|
Nessuna modifica strutturale; Le esecuzioni RPI sono normalmente incluse nelle metriche. |
Flusso di dati di mercato WebSocket
| Canale |
Include Ordini RPI |
Descrizione |
|
|
No |
Dati tick-by-tick di Best Bid/Offer; gli ordini RPI sono esclusi dai calcoli. |
|
|
No |
Le quotazioni sulla profondità del mercato e gli ordini pendenti RPI non sono inclusi nella spinta |
|
|
Sì (nuovo) |
Aggiunge un nuovo canale push per aggregare gli ordini in sospeso relativi all'indice dei prezzi al consumo (RPI). Il protocollo è coerente con il canale di profondità, consentendo ai market maker di abbonarsi in modo indipendente ai dati di profondità completi, incluso l'RPI. |
|
|
No |
Profondità MBP incrementale; gli ordini RPI non sono inclusi nell'operazione. |
|
|
No |
Istantanea piena del MBP; gli ordini RPI non sono inclusi nell'aggiornamento. |
Piazzamento ordine e richieste endpoint (REST)
| Nome endpoint |
Richiesta HTTP |
Descrizione modifica |
| Piazzamento ordini Spot |
|
Aggiunge il campo relativo al tempo di validità (valore: rpi). |
| Piazzamento ordini batch |
|
Aggiunge il campo relativo al tempo di validità (valore: rpi). |
| Piazzamento ordini margin |
|
Aggiunge il campo relativo al tempo di validità (valore: rpi). |
| Ordini aperti richiesta corrente |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). |
| Dettagli richiesta ordine |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). Viene aggiunto un nuovo valore enum rpi_cancel dell'origine annullata, a indicare che l'ordine è stato annullato dal sistema a causa dell'incrocio del prezzo con un ordine non RPI. |
| Richiesta per clientOrderID |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). Viene aggiunto un nuovo valore enum rpi_cancel dell'origine annullata, a indicare che l'ordine è stato annullato dal sistema a causa dell'incrocio del prezzo con un ordine non RPI. |
| Dettagli trading |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). Viene aggiunto un nuovo valore enum rpi_cancel dell'origine annullata, a indicare che l'ordine è stato annullato dal sistema a causa dell'incrocio del prezzo con un ordine non RPI. |
| Cerca storico ordine |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). Viene aggiunto un nuovo valore enum rpi_cancel dell'origine annullata, a indicare che l'ordine è stato annullato dal sistema a causa dell'incrocio del prezzo con un ordine non RPI. |
| Storico ordine ultime 48 ore |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). Viene aggiunto un nuovo valore enum rpi_cancel dell'origine annullata, a indicare che l'ordine è stato annullato dal sistema a causa dell'incrocio del prezzo con un ordine non RPI. |
| Trading storico corrente |
|
Alla risposta viene aggiunto un nuovo campo relativo al periodo di validità (il valore rpi indica un ordine RPI). |
Ordine Push (WebSocket)
| Canale |
Descrizione |
Descrizione modifica |
|
|
Aggiornamento ordine push |
È stato aggiunto un nuovo campo relativo al tempo di validità (valore: rpi), che consente di distinguere in tempo reale gli ordini RPI dagli ordini regolari. |
|
|
Aggiornamenti sulle transazioni post-compensazione e sulla cancellazione degli ordini |
Viene aggiunto un nuovo campo relativo al tempo di validità (valore: rpi); viene aggiunto un nuovo valore enum per la sorgente annullata, rpi_cancel, che consente l'identificazione in tempo reale degli annullamenti attivati dall'incrocio dei prezzi. |
Quanto sopra conclude la documentazione sugli ordini RPI.
