Gestión de pedidos: mejores prácticas

Cola TCP y del lado del cliente: En primer lugar, es posible que su pedido permanezca brevemente en el búfer de envío TCP de su conexión. Se trata de una cola específica de un cliente no se comparte con otros participantes. La alta latencia de la red o el envío de grandes ráfagas de datos pueden provocar que se acumule

Colas de nodos de entrada de Deribit: Dentro del nodo de Deribit que recibió su pedido, hay grupos de subprocesos independientes para los diferentes tipos de solicitudes. Por ejemplo, las solicitudes de datos «públicas» (como las suscripciones a datos de mercado) pueden usar un grupo compartido, mientras que las acciones «privadas» (como realizar o cancelar pedidos) usan un grupo diferente. Las solicitudes de pedidos privados de tu sesión suelen ir a una cola dedicada a tu conexión (no se comparten con otras personas), mientras que algunos feeds públicos se procesan en colas compartidas. Este diseño evita, por ejemplo, que un feed público lento bloquee los comandos de tus pedidos privados

Comunicación entre nodos: Si el nodo de puerta de enlace necesita comunicarse con el motor maestro de comparación u otros nodos (mediante el protocolo de distribución de Erlang), esos mensajes pasan por un canal TCP interno. Se puede considerar este canal entre nodos compartido en el sentido de que los mensajes de muchos participantes podrían fluir a través de él, lo que podría hacer cola debido a una carga elevada.

Cola de bloqueo a nivel de usuario: En la capa del motor correspondiente, Deribit impone un orden de acciones por usuario y por moneda. Todas las solicitudes que afectan a la cuenta de un solo usuario para una moneda determinada se canalizan a través bloqueo del proceso de usuario. Esto significa que si envías varias acciones (pedidos, cancelaciones) en la misma cuenta y en la misma divisa, se ejecutarán de forma secuencial en el orden en que se recibieron. Si tienes varias conexiones (o claves de API) en la misma cuenta que operan en la misma divisa, seguirán compartiendo esta cola para mantener la coherencia. Esta cola está compartida entre todas las conexiones de ese usuario para esa moneda.

Cola de motores coincidente: Por último, el proceso de la cartera de pedidos de cada instrumento tiene su propia cola para los pedidos entrantes y las cancelaciones. Aquí es donde su pedido compite en última instancia con otros. Esto se comparte por todos los participantes que negocian ese instrumento: solo se puede procesar una acción a la vez por cartera de pedidos. Si llegan varios pedidos más o menos al mismo tiempo, pasarán a formar una cola aquí brevemente antes de ser igualados en secuencia

Utilice WebSocket o FIX en lugar de REST: Las conexiones WebSocket (JSON-RPC) y FIX son persistentes y están optimizadas para una baja latencia, mientras que REST genera una sobrecarga adicional por solicitud. De hecho, WebSocket y FIX ofrecen una latencia casi idéntica en la mayoría de los casos. FIX puede ser ligeramente más rápido para ciertas acciones, como las cancelaciones masivas, porque evita algunas colas, pero tiene menos funciones en comparación con WebSockets. REST, por otro lado, es un poco más lento, ya que cada solicitud HTTP debe configurarse, autorizarse y procesarse En pocas palabras: si realiza pedidos frecuentes o necesita velocidad en tiempo real, prefiera WebSocket o FIX. Use REST solo para solicitudes poco frecuentes o si la simplicidad es más importante

Mantenga una conexión ligera: Evite enviar o recibir una cantidad excesiva de datos en la misma conexión, ya que las ráfagas grandes pueden llenar la canalización TCP y el analizador JSON. Por ejemplo, si te suscribes a todos los ticks de cientos de instrumentos en el mismo WebSocket que utilizas para operar, la avalancha de datos entrantes podría retrasar el procesamiento de tus mensajes de pedido. Puede ser una buena idea separar las suscripciones con muchos datos del mercado y colocarlas en una conexión diferente a la de entrada de órdenes o, al menos, reducir el volumen de

Envía ráfagas modestas de pedidos: Si tienes que enviar muchos pedidos, evita enviar lotes muy grandes de una sola vez. Si bien la canalización de Deribit puede procesar grandes volúmenes, enviar «decenas de pedidos a la vez» en una sola ráfaga con el mismo instrumento o moneda puede generar atrasos y aumentar la latencia para los pedidos posteriores (un «efecto bola de nieve»). En su lugar, considera la posibilidad de escalonar ligeramente los lotes o utilizar varias conexiones (o subprocesos) para envíos muy grandes, dividiéndolas por

Para la creación de mercado de alta frecuencia, el Cotizaciones masivas la funcionalidad ofrece un enfoque más eficiente. En lugar de enviar muchas solicitudes individuales de colocación de pedidos, Mass Quotes le permite enviar o actualizar varios pares de oferta y demanda para uno o más instrumentos en una sola llamada a la API. Esto reduce la sobrecarga por pedido, reduce el tráfico de la red y ayuda a mantener baja la latencia, incluso cuando se cotizan varios

Recuerde que dentro de una moneda única, las solicitudes se serializan por usuario. Si envías 50 pedidos de BTC de una sola vez, los pondrás en cola de forma secuencial; las cotizaciones masivas o un ritmo cuidadoso pueden ayudarte a alcanzar los mismos objetivos de cotización con menos colas y una respuesta global más rápida.

Optimice las condiciones de la red: Asegúrese de que su servidor comercial tenga una ruta de red rápida y confiable a los servidores de Deribit. Si eres sensible a la latencia, considera hospedarlo en una ubicación cercana al centro de datos de Deribit (la LD4 de Londres es la bolsa principal). Las conexiones externas a Internet pasan por equilibradores de carga y tienen rutas más largas, lo que añade un poco de latencia (del orden de microsegundos para el salto LB, más cualquier retraso geográfico). Algunas empresas optan colocación para reducir el tiempo de ida y vuelta. Si bien se trata de una cuestión de infraestructura que va más allá de la propia API, es un factor importante en los escenarios de carreras.

Portafolios de gran tamaño — Un número muy elevado de posiciones abiertas aumenta las actualizaciones y la sincronización incrementales de la cartera necesarias.

Actividad de alto nivel — Una gran cantidad de órdenes abiertas activas conduce a cálculos de márgenes más pesados.

Congestión de colas — Si hay muchas conexiones y solicitudes pendientes de acceso a la cartera, es posible que las comprobaciones se retrasen.

Todos los tipos de pedidos se procesan con las mismas comprobaciones de riesgo. Los indicadores de reducción exclusiva o las instrucciones de caducidad (p. ej., GFD o IOC) no afectan

Cancelar solicitudes (cancel, cancel_all, cancel_by_label) también pasan por la lista de espera de carteras, pero se ejecutan sin comprobar el riesgo.

Citas masivas son la única excepción: omiten la mayoría de las comprobaciones de riesgo para respaldar las cotizaciones de alto rendimiento.

10047 matching_engine_queue_full: La lista de espera de Portfolio puede contener hasta 8 procesos en espera. Si está llena, las nuevas solicitudes se rechazarán con este error. En FIX, esto aparece como demasiadas solicitudes.

10050 lock_time_exceeded: Si una solicitud no puede completar el procedimiento de bloqueo en 5 segundos, se agota el tiempo de espera, incluso si hay menos de 8 procesos en espera.

Cancelar un solo pedido: Puedes cancelar por identificador de pedido mediante el privado/cancelar método (proporcionando lo específico order_id). Esto es sencillo para las cancelaciones puntuales

Cancelar por etiqueta: Si etiquetas tus pedidos con una etiqueta (una cadena de hasta 64 caracteres definida por el usuario) al realizarlos, puedes cancelar todos los pedidos con esa etiqueta en una sola llamada a través de private/cancel_by_label. Esto es útil para agrupar y gestionar los pedidos relacionados. Por ejemplo, puedes etiquetar todos los pedidos de una estrategia o instrumento en particular y, después, cancelarlos de una vez por etiqueta.

Cancelar todos los pedidos:privado/cancel_todos intentará cancelar cada abra órdenes en su cuenta, en todos los instrumentos y divisas. Si bien es conveniente, esta es la llamada de cancelación más pesada porque lo cubre todo

Cancelar todo en una moneda:privado/cancel_todo_por_divisa es una cancelación masiva más específica: cancelará todos los pedidos en una moneda determinada (por ejemplo, todos los pedidos en BTC o todos los pedidos en ETH). Incluso puedes filtrar por tipo de instrumento o tipo de orden si es necesario (por ejemplo, solo opciones o solo órdenes suspendidas).

Cancelar todo en un instrumento:privado/cancel_todo_por_instrumentocancelará todos los pedidos de un instrumento específico (p. ej., una opción concreta o futura).

Cancele cotizaciones a través de Mass Quotes: Si cotiza varios instrumentos, utilice el Cotizaciones masivas función, puede cancelar todas las cotizaciones activas en una sola llamada a la API (private/cancel_quotes). Esto es más eficaz que cancelar cada orden cotizada de forma individual y es particularmente útil para los creadores de mercado que gestionan grandes carteras de cotización con varios instrumentos

Uno o más eventos de negociación o llenado para los 500 que han negociado (a través del user.trades. * canal o informes de ejecución).

Un evento de cancelación de un pedido que indique que el pedido ya no está activo (a través del user.orders. * canal).

De forma predeterminada, si una orden solo posterior cruzara el diferencial y se ejecutara, Deribit lo hará automáticamente ajustará el precio basta con marcar una casilla dentro del diferencial para asegurarse de que se convierte en un pedido del fabricante. Por ejemplo, supongamos que el mejor pedido es de 10.000€ y envías una orden de compra con post_only a 11.000. En lugar de formalizar el pedido a 10 000$, el sistema colocará tu pedido a 9.999,50$ (suponiendo una marca de 0,50$), justo por debajo de la mejor oferta, para que quede en el libro sin ejecutarse. Este comportamiento garantiza que tu intención de publicar solo se respete

Si prefiere que la orden no se ejecute estrictamente y no ajustada, puede activar el rechazar solo por correo función. En la API JSON, esto se hace con "reject_post_only«: true (y en FIX, usando ExecInst 6A en lugar de 6). Con esta configuración, si tu pedido solo por correo provoca una coincidencia inmediata, el sistema rechazará el pedido en lugar de ajustar el precio. Esto te da más control, ya que el pedido se realiza sin modificar a tu precio (sin igualación) o no lo consigues. Algunos operadores utilizan esta opción para evitar incluso la ligera diferencia de precio, y prefieren rechazarla rotundamente si la orden no está

Edición de órdenes solo por publicación: si editas una orden existente solo por publicación de manera que sea agresiva (por ejemplo, moviendo su precio a un nivel que se compararía con el libro actual), el comportamiento depende del modo:

display_amount — la punta visible del pedido.

refresh_amount — la cantidad fija utilizada para reponer la parte visible cuando se llena.

Al menos 100 veces el tamaño mínimo de pedido del instrumento.

Al menos el 1% del tamaño total del pedido.

El refresh_amount permanece constante; solo el display_amount cambia a medida que se completa el pedido.

Las partes ocultas se ejecutan inmediatamente cuando se comparan e incurren Comisiones del tomador.

Las órdenes Iceberg son útiles para ejecutar grandes operaciones de forma discreta sin revelar su tamaño total al mercado.

OTO — Uno desencadena al otro: Esto implica una orden principal y una o más órdenes secundarias que permanecen inactivas hasta que se ejecute la orden principal. Cuando la orden principal se llena total o parcialmente (según la condición desencadenante) desencadena los pedidos secundarios que se van a realizar. Por ejemplo, quieres comprar 100 BTC-PERP si el precio cae a 20 000$ y, si ese pedido se completa, quieres realizar inmediatamente una orden de venta con fines de lucro a 22 000$. Se trata de una configuración de «uno desencadena a la otra»: la compra es la principal; la venta es secundaria y solo entrará en el libro una vez que se haya ejecutado

OCO — Uno cancela otro: Esto vincula dos órdenes de manera que si una orden se ejecuta, la otra se cancela automáticamente. Un caso de uso común es poner entre corchetes el mercado detenga las pérdidas y obtenga ganancias. Es posible que tengas una orden de cierre bursátil para vender si el precio cae a 19 000$ y una orden de venta limitada para obtener beneficios de 22 000$, ambas para el mismo tamaño de posición. Lo único que quieres es que una de ellas acabe imponiéndose: lo que ocurra primero anula la otra. Estos dos pedidos se vincularían como OCO. Si el stop se activa y se completa, la toma de ganancias se cancela y viceversa.

OTOCO — Uno activa, uno cancela otro: Básicamente, se trata de combinar OTO y OCO. Tiene una orden principal y, al ejecutarla, activa dos órdenes secundarias que, a su vez, están en una relación de OCO. Este es el clásico entrada con corchete de salida escenario. Por ejemplo, ingresas una posición larga (orden principal). Cuando se llena, activa la colocación simultánea de una orden de stop loss y una orden de obtención de beneficios (las dos secundarias). Estas dos órdenes secundarias están vinculadas entre sí, por lo que solo una puede ejecutarse en última instancia: si se alcanza el objetivo de beneficios, se cancela el stop o, si se alcanza el stop, se cancela la orden de obtención de beneficios. De este modo, OTOCO automatiza todo el ciclo: la entrada, con una salida protegida en ambos sentidos. Es muy útil para las operaciones sin intervención, ya que garantiza la gestión del riesgo y la obtención de beneficios sin intervención manual

Redondeo de los promedios de las posiciones: Cuando su posición cambia como resultado de las operaciones, Deribit calcula el nuevo precio de entrada promedio como total_cost / total_quantity. Internamente, los costos en USD se mantienen con alta precisión (hasta 8 decimales) y los montos en BTC con hasta 12 decimales. Sin embargo, para fines de visualización, el precio promedio se redondea a 2 decimales. Esto significa que el PnL que se muestra en la interfaz de usuario se basa en el precio promedio redondeado, mientras que los cálculos internos y la liquidación final utilizan los valores exactos. Si concilias los costes de las posiciones, ten en cuenta que pueden aparecer pequeñas diferencias de redondeo entre lo que ves en la interfaz y el cálculo exacto

Identificadores de pedidos y transacciones: Cada pedido y operación que reciba del sistema tiene un identificador único. Estos identificadores no son secuenciales a nivel mundial, pero se garantiza que son únicos y aumentan con el tiempo. Por ejemplo, sus identificadores de operaciones aumentarán, pero no se utilizarán todos los números (podrían existir lagunas, especialmente si se realizan operaciones en otras cuentas o instrumentos). Puedes confiar en el hecho de que una operación posterior tendrá un identificador más alto que una operación anterior, pero no en que sea exactamente +1. Lo mismo ocurre con los números de pedido: no son consecutivos, sino que aumentan de forma monótona en general

Cancelación al desconectar (CoD): Deribit ofrece una función opcional, desactivada de forma predeterminada, llamada cancelar al desconectar (CoD). Cuando está habilitada, cancela automáticamente los pedidos activos si se pierde la conexión a la API. Esto se aplica tanto a las sesiones FIX como a las de WebSocket. Si aplicas estrategias en las que una caída de conexión podría dejar sin supervisión las órdenes en el mercado, activar el CoD puede ayudar a mitigar

CoD debe habilitarse explícitamente a través de la API o en la configuración de la interfaz web. Si no está habilitada y tu conexión se interrumpe, tus pedidos permanecerán activos hasta que los canceles manualmente, se cancelen mediante otra acción, se completen por completo o caduquen.

Para obtener instrucciones detalladas sobre cómo habilitar y administrar CoD, consulte la Artículo sobre administración de conexiones o el documentación de la API.

Límites de tarifas: Si bien no se trata directamente en la sección anterior, recuerde que Deribit tiene Límites de velocidad de API. Los comportamientos apresurados, como enviar muchos pedidos o cancelar rápidamente, están sujetos a límites. Si alcanzas un límite de velocidad, la sesión se desconectará y podría anular tus ganancias de latencia. La mejor práctica es mantenerse dentro de los límites documentados o ponerse en contacto con Deribit si necesita umbrales más altos para

Prueba en el entorno Testnet: Si está implementando una lógica de pedidos compleja (como OTOCO o estrategias de alta frecuencia), realice siempre la prueba test.deribit.com primero. La API es prácticamente idéntica y puedes simular escenarios (incluidos rellenados parcialmente, cancelaciones, etc.) sin arriesgar fondos reales. Esto también puede confirmar que entiendes correctamente las llamadas a la API (especialmente en el caso de los pedidos vinculados). Por favor, consulte Artículos relacionados con Testnet para obtener más detalles.