Prevención de autonegociación (STP)
Protección automática contra la autonegociación.
Descripción general
Cuando una orden entrante (taker) coincidiría con una orden en reposo (maker) de la misma wallet, el motor cancela ambas órdenes en lugar de ejecutarlas. Esto evita el wash trading y protege a los market makers de cruzar accidentalmente sus propias cotizaciones.
STP está siempre activo. No hay configuración, ni forma de desactivarlo, ni modos alternativos.
Comportamiento
Estrategia: cancelar ambas
Cuando se detecta una autonegociación:
- La orden maker se cancela con el motivo
"Self-trade prevention" - La orden taker se rechaza (si no tiene ejecuciones previas) o se cancela (si se ejecutó parcialmente)
No se genera ninguna ejecución entre las dos órdenes.
Coincidencia a nivel de wallet
STP compara direcciones de wallet, no claves de agente. Si usted utiliza la autorización de agentes para firmar órdenes desde varias claves, todas las órdenes bajo la misma wallet de trading están sujetas a STP entre sí.
Las ejecuciones parciales se conservan
Si una orden taker se ejecuta contra otras contrapartes antes de encontrar una autonegociación, esas ejecuciones se conservan.
Ejemplo: El libro tiene 5 contratos ofrecidos por la Wallet B y luego 5 contratos ofrecidos por la Wallet A. La Wallet A envía una compra de 10 contratos:
| Paso | Coincide con | Resultado |
|---|---|---|
| 1 | Wallet B (5 contratos) | Ejecución: 5 contratos ejecutados |
| 2 | Wallet A (5 contratos) | Autonegociación detectada |
Resultado:
- La Wallet A recibe una ejecución de 5 contratos contra la Wallet B
- La orden maker de la Wallet A (5 contratos) se cancela
- La orden taker de la Wallet A se cancela con
filled_size: 5
Estado de la orden
| Escenario | Estado del taker | Motivo |
|---|---|---|
| Sin ejecuciones previas | REJECTED | "Self-trade prevention" |
| Ejecuciones parciales antes de la autonegociación | CANCELED | "Self-trade prevention (partial fill kept)" |
La orden maker siempre queda CANCELED con el motivo "Self-trade prevention".
Las órdenes GTC no quedan en reposo tras una autonegociación
Si una orden taker GTC activa STP, la cantidad restante no se añade al libro, aunque la orden normalmente quedaría en reposo. La orden se termina por completo.
Notificaciones por WebSocket
Tanto la cancelación o el rechazo del taker como los del maker se entregan en el canal order_updates. El campo reason indica que la causa fue STP.
Preguntas frecuentes
¿Puedo elegir un modo de STP diferente (por ejemplo, cancelar la más reciente o reducir)? No. Hypercall utiliza exclusivamente la cancelación de ambas órdenes.
¿Se aplica STP a las órdenes de perpetuos? No. El STP de Hypercall se aplica a las órdenes que se emparejan en el libro de Hypercall: órdenes de opciones y órdenes combinadas. Las órdenes de perpetuos se emparejan en el libro de órdenes de Hyperliquid, donde se aplican las propias reglas de autonegociación de Hyperliquid.
¿Se aplica STP a las órdenes combinadas? Sí. El emparejamiento se detiene antes de que una ruta combinada o implícita haga que una cuenta opere contra sí misma, y la orden maker en reposo se cancela. Consulte la API experimental de combos para los casos de todo o nada (FOK y reemplazo atómico).
¿Se aplica STP a las operaciones RFQ? Sí. Si el taker y un proveedor de cotizaciones comparten la misma wallet, la cotización se rechaza.
Soy market maker y cotizo ambos lados. ¿Se cancelarán mis cotizaciones entre sí? Solo si una orden entrante hiciera que se crucen. Las órdenes en reposo en lados opuestos del libro a precios diferentes coexisten con normalidad. STP solo se activa en el momento del emparejamiento.