Resumen
El flujo ORDER_PRIORITY proporciona eventos normalizados de órdenes con tarifa prioritaria a partir de los datos Hyperliquid . Emite un evento JSON por cada acción de orden prioritaria, derivada tanto de las transacciones del mempool como de los datos de los bloques confirmados.
Tipo de arroyo: ORDER_PRIORITY
Disponibilidad de la API: Solo API gRPC
Volumen: Variable: depende de la actividad relacionada con los pedidos de tarifas por prioridad
Utiliza ORDER_PRIORITY cuando quieras observar flow de órdenes con comisión por prioridad flow analizar los datos sin procesar. MEMPOOL_TXS o completo BLOQUES/replica_cmds cargas útiles por tu cuenta. Este flujo es unflow , no un flujo del libro de órdenes.
Esta transmisión resulta útil para:
- Seguimiento de las tarifas prioritarias: realiza un seguimiento en tiempo real de los pedidos con tarifas prioritarias
- Análisis de tarifas: analizar las tendencias de las tarifas de prioridad en distintos mercados
- Flow de órdenes: comprender los patrones de envío de órdenes prioritarias
- Visibilidad previa a la confirmación: consulta los pedidos prioritarios del mempool antes de su inclusión en el bloque
- Seguimiento de confirmaciones: supervisar los resultados de la ejecución de los pedidos prioritarios
Fuentes de datos
El flujo ORDER_PRIORITY obtiene eventos de dos fuentes:
| Fuente | Descripción | Campos adicionales |
|---|---|---|
| mempool_txs | Actividad prioritaria previa al consenso procedente del mempool. Los eventos no están confirmados y pueden ser rechazados, reordenados o no aparecer en la cadena final. | first_seen_time, tx_hash, nonce, cloid |
| replica_cmds | Datos de bloque confirmados que representan el procesamiento finalizado de las transacciones. | número_de_bloque, hora_del_bloque, índice_del_paquete, resultado |
Detección de prioridades
Los pedidos prioritarios se detectan cuando una acción de pedido contiene el agrupación campo con un valor de tarifa prioritaria:
"grouping": { "p": 10000 }
Valores de las tasas de prioridad
El p Este valor representa la tarifa de prioridad, y su rango depende de la red y del tipo de pedido.
Los valoresTestnet se expresan en puntos básicos (pb):
| Valor p | Puntos básicos | Notas |
|---|---|---|
| 10000 | 1 pb | Base (p = 10 000 equivale a 1 pb) |
| 80000 | 8 puntos básicos | Importe mínimo de las comisiones de prioridad de testnet |
| 1000000 | 100 puntos básicos | Importe máximo de las comisiones por prioridad de testnet |
Mainnet son muy diferentes del rango testnet . Ten en cuenta las unidades al compararlas: p es un entero sin formato que se interpreta como la fracción p / 100 000 000, por lo que 1 pb equivale a un valor bruto p de 10000, y el rango testnet de 8-100 bps se corresponde con el valor sin procesar p valores de 80000 a 1000000. La actividad prioritaria en mainnet principalmente Pedidos de ALO con una cantidad de materia prima mucho menor p valores, que suelen oscilar entre 1 y, más o menos, 400 (aproximadamente 0,04 pb en el extremo superior), a menudo en escaleras por usuario, ya que las órdenes compiten por la posición en la cola. Una proporción mucho menor de las órdenes mainnet son COI, y estos pueden transportar mayores p valores (valores sin procesar arriba 10000 (según se ha observado), aunque sigue estando muy por debajo del rango de testnet bps testnet en el tráfico observado.
Según el Documentación oficial sobre las tasas Hyperliquid, las órdenes ALO realizadas al mismo nivel de precio dentro de un T = 400 ms Las órdenes de la ventana se ordenan por orden descendente de tasa de prioridad, y las comisiones de prioridad de ALO se deducen, al realizar la orden, del saldo de staking no delegado, convertido a HYPE utilizando el precio de referencia al contado.
En testnet:
- Las comisiones prioritarias del IOC se sitúan en un rango de entre 8 y 100 puntos básicos
- Las órdenes de ALO dan lugar a comisiones prioritarias
- Dentro del rango de IOC de 8-100 bps, las comisiones de prioridad se utilizan como mecanismo de clasificación para las órdenes recibidas aproximadamente al mismo tiempo y tienen el mismo efecto de priorización en el mempool.
La prioridad ALO afecta a la posición en la cola tras la ejecución de L1 y no ofrece el mismo comportamiento de priorización en el mempool que la prioridad IOC.
testnet Mainnet testnet admiten los tipos gRPC . Los eventos reales y los observados p Los rangos dependen de la actividad prioritaria que se esté llevando a cabo en la red seleccionada.
Estructura del evento
Evento de mempool
{
"type": "order",
"source": "mempool_txs",
"first_seen_time": "2026-06-02T13:48:49.578877529",
"tx_hash": "0x...",
"signed_action_index": 0,
"order_index": 0,
"asset_id": 0,
"market_type": "perp",
"coin": "BTC",
"cloid": "0x...",
"p": 10000,
"side": "buy",
"px": "100000",
"sz": "0.001",
"tif": "Ioc",
"reduce_only": false,
"nonce": 1780408128806
}
Evento confirmado (fuente: replica_cmds)
{
"type": "order",
"source": "replica_cmds",
"block_number": 581285917,
"block_time": "2026-06-02T13:48:49.626754186",
"bundle_index": 0,
"asset_id": 0,
"market_type": "perp",
"coin": "BTC",
"p": 10000,
"side": "buy",
"px": "100000",
"sz": "0.001",
"tif": "Ioc",
"reduce_only": false,
"outcome": "filled"
}
Campos de respuesta
| Campo | Tipo | Descripción |
|---|---|---|
| tipo | cadena | Tipo de evento: «pedido» |
| fuente | cadena | Fuente de datos: «mempool_txs» (antes del consenso) o «replica_cmds» (confirmadas) |
| fecha_de_la_primera_visita | cadena | (solo mempool_txs) Marca de tiempo ISO 8601 de la primera vez que se vio en el mempool |
| tx_hash | cadena | (solo mempool_txs) Hash de la transacción (con prefijo 0x) |
| índice_de_acciones_firmadas | número | (solo mempool_txs) Índice de la acción firmada dentro de la transacción |
| índice de pedidos | número | (solo mempool_txs) Índice del orden dentro de la acción |
| número_de_bloque | número | (solo replica_cmds) Número de bloque en el que se confirmó la orden |
| block_time | cadena | (solo replica_cmds) Marca de tiempo ISO 8601 del bloque |
| índice_del_paquete | número | (solo replica_cmds) Índice del paquete dentro del bloque |
| asset_id | número | Identificador numérico del activo o la moneda |
| tipo_de_mercado | cadena | Tipo de mercado (p. ej., «perp») |
| moneda | cadena | Símbolo del par de negociación (p. ej., «BTC», «ETH») |
| cloide | cadena | (opcional) Número de pedido del cliente |
| p | número | Valor bruto de la comisión de prioridad, expresado como la fracción p / 100 000 000 (10 000 = 1 bp). Las órdenes Testnet utilizan valores entre 80 000 y 1 000 000 (8-100 bps); las órdenes mainnet tienen valores mucho menores, normalmente entre 1 y ~400 (hasta ~0,04 bp). |
| lado | cadena | Lado de la orden: «comprar» o «vender» |
| px | cadena | Precio del pedido |
| sz | cadena | Volumen del pedido |
| tif | cadena | Vigencia: «Ioc» (Inmediato o Cancelar) o «Alo» (Solo añadir liquidez) |
| reduce_only | booleano | Si la orden solo puede reducir una posición existente |
| nonce | número | (solo mempool_txs) Nonce de la transacción |
| usuario | cadena | (opcional) Dirección del usuario |
| locutor | cadena | (opcional) Dirección del emisor |
| resultado | cadena | (solo replica_cmds) Resultado de la ejecución (p. ej., «ejecutada») |
Pedidos prioritarios de ALO
Las órdenes prioritarias «Solo añadir liquidez» (ALO) tienen tif establecer en «Alo»:
{
"tif": "Alo"
}
Filtrado
El flujo ORDER_PRIORITY admite el filtrado gRPC estándar gRPC . Campos útiles:
| Campo | Valores de ejemplo | Descripción |
|---|---|---|
| fuente | mempool_txs, replica_cmds | Filtrar por fuente de datos |
| tipo | pedido | Filtrar por tipo de evento |
| moneda | BTC, ETH, SOL | Filtrar por par de divisas |
| tipo_de_mercado | perp | Filtrar por tipo de mercado |
| asset_id | 0, 1, 2 | Filtrar por ID de activo |
| p | 10000, 80000, 1000000 | Filtrar por el valor de la tasa de prioridad |
| lado | comprar, vender | Filtrar por lado del pedido |
| tif | Ioc, Alo | Filtrar por período de vigencia |
| resultado | relleno | Filtrar por resultado de la ejecución (solo replica_cmds) |
| usuario | 0x... | Filtrar por dirección de usuario |
| locutor | 0x... | Filtrar por dirección de la emisora |
| tx_hash | 0x... | Filtrar por hash de transacción |
| número_de_bloque | 581285917 | Filtrar por número de bloque |
Ejemplos de filtros
// Get BTC priority orders only
filters: {
"coin": FilterValues { values: ["BTC"] }
}
// Get IOC priority orders from mempool
filters: {
"source": FilterValues { values: ["mempool_txs"] },
"tif": FilterValues { values: ["Ioc"] }
}
// Get filled priority orders from confirmed blocks
filters: {
"source": FilterValues { values: ["replica_cmds"] },
"outcome": FilterValues { values: ["filled"] }
}
// Get high-value priority fees (8+ bps)
filters: {
"p": FilterValues { values: ["80000", "100000", "500000", "1000000"] }
}
Para consultar la documentación completa sobre el filtrado, véase la Guía de filtrado de flujos.
Uso recomendado
Paraflow con baja latencia:
ORDER_PRIORITY + source=mempool_txs
Para su confirmación y conciliación:
ORDER_PRIORITY + source=replica_cmds
Los clientes deben almacenar los eventos si necesitan realizar búsquedas en el historial. StreamData es una transmisión en directo y, por sí sola, no ofrece la posibilidad de reproducir el historial.
gRPC
Ejemplo en Python
import grpc
import json
from pb import streaming_pb2, streaming_pb2_grpc
GRPC_ENDPOINT = 'your-endpoint.hype-mainnet.quiknode.pro:10000'
AUTH_TOKEN = 'your-auth-token'
def stream_order_priority():
credentials = grpc.ssl_channel_credentials()
channel = grpc.secure_channel(
GRPC_ENDPOINT,
credentials,
options=[
('grpc.max_receive_message_length', 100 * 1024 * 1024),
]
)
stub = streaming_pb2_grpc.StreamingStub(channel)
metadata = [('x-token', AUTH_TOKEN)]
def request_generator():
# Subscribe to ORDER_PRIORITY with filters
subscribe_request = streaming_pb2.SubscribeRequest()
subscribe_request.subscribe.stream_type = streaming_pb2.StreamType.ORDER_PRIORITY
subscribe_request.subscribe.filters["coin"].values.extend(["BTC", "ETH"])
subscribe_request.subscribe.filters["tif"].values.append("Ioc")
yield subscribe_request
# Keep connection alive with periodic pings
while True:
time.sleep(30)
ping_request = streaming_pb2.SubscribeRequest()
ping_request.ping.timestamp = int(time.time() * 1000)
yield ping_request
stream = stub.StreamData(request_generator(), metadata=metadata)
for response in stream:
if response.HasField('data'):
data = json.loads(response.data.data)
print(f"Priority Order Event")
print(f"Source: {data.get('source')}")
print(f"Coin: {data.get('coin')}")
print(f"Priority Fee (p): {data.get('p')} ({data.get('p', 0) / 10000} bps)")
print(f"Side: {data.get('side')}")
print(f"Price: {data.get('px')}")
print(f"Size: {data.get('sz')}")
print(f"TIF: {data.get('tif')}")
if data.get('source') == 'replica_cmds':
print(f"Outcome: {data.get('outcome')}")
print(f"Block: {data.get('block_number')}")
print("---")
if __name__ == "__main__":
stream_order_priority()
Ejemplo de JavaScript/Node.js
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const GRPC_ENDPOINT = 'your-endpoint.hype-mainnet.quiknode.pro:10000';
const AUTH_TOKEN = 'your-auth-token';
// Load proto file
const packageDefinition = protoLoader.loadSync('streaming.proto');
const proto = grpc.loadPackageDefinition(packageDefinition).hyperliquid;
// Create channel with credentials
const credentials = grpc.credentials.createSsl();
const client = new proto.Streaming(GRPC_ENDPOINT, credentials);
const metadata = new grpc.Metadata();
metadata.add('x-token', AUTH_TOKEN);
// Subscribe to ORDER_PRIORITY
const call = client.StreamData(metadata);
call.on('data', (response) => {
if (response.data) {
const data = JSON.parse(response.data.data);
console.log(`Priority Order Event`);
console.log(`Source: ${data.source}`);
console.log(`Coin: ${data.coin}`);
console.log(`Priority Fee (p): ${data.p} (${data.p / 10000} bps)`);
console.log(`Side: ${data.side}`);
console.log(`Price: ${data.px}`);
console.log(`Size: ${data.sz}`);
console.log(`TIF: ${data.tif}`);
if (data.source === 'replica_cmds') {
console.log(`Outcome: ${data.outcome}`);
console.log(`Block: ${data.block_number}`);
}
console.log('---');
}
});
call.on('error', (error) => {
console.error('Stream error:', error);
});
// Send subscription with filters
call.write({
subscribe: {
stream_type: 9, // ORDER_PRIORITY
filters: {
coin: { values: ['BTC', 'ETH'] },
tif: { values: ['Ioc'] }
}
}
});
// Send periodic pings
setInterval(() => {
call.write({
ping: { timestamp: Date.now() }
});
}, 30000);
Notas importantes
- Flujo derivado: ORDER_PRIORITY es un flujo derivado que normaliza los datos de MEMPOOL_TXS y BLOCKS, lo que te evita tener que analizar las cargas útiles sin procesar.
- No es un libro de órdenes: este flujo proporciona metadatos sobre la prioridad de las órdenes, no el estado del libro de órdenes.
- Fuentes duales: los eventos proceden tanto del mempool (antes del consenso) como de los bloques confirmados (después del consenso).
- Intervalos específicos de la red - El rango de IOC de 8-100 bps se aplica a testnet corresponde a los datos sin procesar
pvalores de entre 80 000 y 1 000 000 (10 000 = 1 bp); en mainnet, la actividad prioritaria son principalmente las órdenes ALO, con un volumen bruto mucho menorpvalores que suelen oscilar entre 1 y ~400 (hasta ~0,04 pb) - Compresión: considera la posibilidad de habilitar la compresión zstd en tu gRPC para optimizar el ancho de banda.
Streams relacionados
- GOSSIP_PRIORITY - Eventos de puja de «Gossip»/prioridad de lectura
- MEMPOOL_TXS - Transacciones sin procesar del mempool (datos de origen para eventos de prioridad previos al consenso)
- BLOQUES - Datos brutos de la cadena de bloques (datos de origen de los eventos prioritarios confirmados)
- PEDIDOS - Eventos del ciclo de vida de los pedidos
- OPERACIONES - Operaciones realizadas
Para obtener más información sobre la configuración gRPC , consulta la documentacióngRPC .