1. Deribit Soporte
  2. Exchange
  3. Lanzamientos
  4. Lanzamientos de 2025

5 de agosto de 2025

  • Actualización

⚠️ Tiempo de inactividad esperado: 15 a 30 minutos

Impacto en el cliente: Mantenimiento a las 9:00 (hora peninsular española): el sistema permanecerá inactivo entre 15 y 30 minutos. Los sistemas cliente no podrán comunicarse con Deribit durante este tiempo

Bloquear RFQ

Bloquear la preasignación de solicitudes de presupuesto
block_rfq_allocation.png

El método private/create_block_rfq ahora es compatible preasignación. El tomador puede usar el trade_allocations parámetro para dividir el importe total de la solicitud de presupuesto por bloques entre sus cuenta principal, subcuentas, o clientes vinculados a corredores. Cada asignación debe especificar: user_id (para asignación directa) o client_info objeto (para la asignación del corredor) e importe.

La preasignación se admite tanto a través de API y en el Interfaz de página web de Deribit.

Importante

Esta funcionalidad solo está disponible al crear una solicitud de presupuesto en bloque desde la cuenta principal.

Ejemplo para user_id

{
  "method": "private/create_block_rfq",
  "params": {
    "legs": [
      {
        "instrument_name": "BTC-25JUL25",
        "amount": 200000,
        "direction": "buy"
      }
    ],
    "trade_allocations": [
      {
        "user_id": 1354,
        "amount": 100000
      },
      {
        "user_id": 1464,
        "amount": 100000
      }
    ],
    "label": "test",
    "makers": [],
    "disclosed": true
  },
  "jsonrpc": "2.0",
  "id": 6
}

Ejemplo para client_info y user_id

{
  "method": "private/create_block_rfq",
  "params": {
    "legs": [
      {
        "instrument_name": "BTC-PERPETUAL",
        "amount": 200000,
        "direction": "buy"
      }
    ],
    "trade_allocations": [
      {
        "client_info" : {
                "client_id" : 1,
                "client_link_id" : 1
        },
        "amount": 100000
      },
        {
        "user_id" : 7,
        "amount" : 100000
        }
    ],
    "label": "test",
    "makers": [],
    "disclosed": true
  },
  "jsonrpc": "2.0",
  "id": 6
}

Requisitos clave:

  • Los tamaños asignados deben alinearse con el importe mínimo de negociación de los instrumentos subyacentes (como ocurre con las cotizaciones)

  • El suma de todas las asignaciones debe ser igual al tamaño total de la solicitud de presupuesto

  • Las asignaciones pueden estar por debajo del tamaño mínimo de bloque, siempre y cuando el total cumpla con el requisito

  • Las asignaciones son inmutables una vez creada la solicitud de presupuesto

Verificaciones de márgenes

  • El margen está validado por cuenta asignada en el momento de la creación de la solicitud de presupuesto.

  • El el creador no necesita fondos si no se está asignando a sí mismo.

  • En caso de una verificación fallida, se informará al corredor qué asignación falló.

Ciclo de vida y visibilidad de las solicitudes de presupuesto

  • En público, el el creador sigue marcado como tomador.

  • Las asignaciones solo son visibles para el creador y los destinatarios individuales (cada uno ve solo lo suyo).

  • Usuarios asignados en la solicitud de presupuesto no puedo citar en él para evitar la autonegociación.

  • Las RFQ respetan la Configuración SMP (prevención de coincidencias automáticas): no se permite cotizar si algún usuario asignado tiene la misma identidad de solicitud de presupuesto que el creador.

Comportamiento comercial y asignación posterior a la negociación

  • Solo el creador ve el desglose completo de las asignaciones.

  • Usuarios asignados:

    • Ver solo su parte del comercio

    • Puede ver el tamaño total negociado (ya que la solicitud de presupuesto es pública)

  • Las tarifas las pagan los usuarios asignados, pero el la tarifa se basa en el creador de la solicitud de presupuesto, no cuentas individuales.

  • Cuentas asignadas pueden ver sus respectivas operaciones en su registro de transacciones, al igual que con las operaciones normales. Esto incluye los detalles de las comisiones, las marcas de tiempo y los metadatos de las operaciones

Visibilidad comercial en API y suscripciones

Las operaciones asignadas aparecerán en:

Precios indexados en la cinta de comercio público Block RFQ

Se agregaron los index_prices de los instrumentos subyacentes en el momento de la operación a /public/get_block_rfq_trades.

Aviso

Recordatorio de desaprobación

Si tu integración sigue utilizando el método obsoleto private/trade_block_rfq, actualice sus sistemas para utilizarlos /private/accept_block_rfq en su lugar. El método obsoleto se eliminará en la próxima versión

API

En esta versión se incluirán las siguientes actualizaciones de la API:

Cambios importantes
Restricción de visualización de los secretos de las claves de API

  • Claves de API con account:read scope ya no puede ver los secretos de otras claves de API, incluso si esas claves comparten el mismo alcance.

  • Solo claves de API con account:read_write Ahora se permite a los usuarios ver los secretos de las claves de la API.

Cambios irrompibles
Información sobre todos los combos de opciones lineales permitidos

El public/get_index_price_names El método ahora proporciona información sobre la posible creación de combinaciones futuras y de opciones para el índice especificado.

La fecha de caducidad de Block Trade se devuelve en la API

Añadido expires_at para privado/verify_block_trade respuesta.

ARREGLAR

Cambios importantes

ARREGLAR Pedido Cancelar reemplazar (G) el mensaje ahora será compatible DisplayQty(1138) etiqueta en lugar de MaxShow(210)