Saltar al contenido
Financial Context Wiki

Orden post-only

Una orden post-only es una instruccion de orden limitada especifica del centro de negociacion, concebida para quedar en el libro y no tomar liquidez de inmediato; el rechazo, la cancelacion, el ajuste de precio, la prioridad en cola y las comisiones dependen de las reglas exactas de casacion.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Una instruccion post-only, o solo de aporte de liquidez, se adjunta a una orden limitada y se comprueba cuando esta llega al motor de casacion. Si alguna parte se ejecutaria de inmediato contra liquidez en reposo, el centro aplica su propia regla: puede rechazar la solicitud, aceptar y cancelar la orden, o desplazar su precio hasta un nivel no ejecutable de inmediato. Por tanto, post-only expresa una condicion de entrada, no un tipo de orden universal con un unico resultado.

Una orden que queda correctamente en el libro puede negociarse despues cuando llega una orden contraria. Esa ejecucion suele clasificarse como liquidez maker, pero mandan el registro real de la ejecucion y el libro de comisiones. Ni un acuse de recibo, ni el estado open, ni la marca post-only garantizan por si solos la ejecucion, el tratamiento maker, un rebate o un mejor resultado neto.

Como funciona

La ejecutabilidad inmediata se evalua con el estado del motor, no con una pantalla desactualizada. Una compra limitada al mejor ask o por encima de el, y una venta limitada al mejor bid o por debajo, normalmente cruzan el libro. El redondeo al tick, las subastas, los libros bloqueados o cruzados, la liquidez oculta, las protecciones de precio y la prevencion de autonegociacion pueden alterar el resultado. El ajuste automatico tambien cambia el limite solicitado y la posicion en cola, por lo que debe ser una regla del centro aceptada expresamente.

Post-only es independiente de otras instrucciones. GTC, GTD, IOC y FOK regulan la vigencia; algunos centros rechazan post-only junto con instrucciones de ejecucion inmediata. reduce-only, close-only y los campos de lado de posicion regulan la exposicion. Una orden stop o take-profit puede no entrar en el libro hasta activarse; la orden hija convertida se somete entonces a las reglas post-only vigentes del centro.

La cola y el ciclo de vida tambien son especificos. La prioridad precio-tiempo es habitual, pero no universal. Un cambio de precio, un aumento de cantidad o una cancelacion y sustitucion suelen perder prioridad; una reduccion de cantidad compatible puede conservarla. La prevencion de autonegociacion puede cancelar o reducir la orden entrante, la que ya estaba en el libro o ambas. Solo los eventos publicos y privados correctamente ordenados demuestran que ocurrio realmente.

Use este flujo:

  1. Fije el centro, la entidad legal, el producto, la sesion y la version de API; registre tick, lote, nocional minimo, nivel de comisiones y si una post-only ejecutable se rechaza, cancela o ajusta de precio.
  2. Capture una vista de mejor bid, mejor ask y profundidad con timestamp y secuencia coherente; especifique lado, limite, cantidad, vigencia, modo de posicion, post-only, reduce-only, prevencion de autonegociacion y campos de activacion.
  3. Redondee precio y cantidad exactamente y compruebe cruce, bandas de precio, saldos, margen, limites de orden y modos incompatibles, considerando autoritativo el estado a la llegada al motor.
  4. Envie con un identificador de orden de cliente unico; separe el exito del transporte de los estados aceptada, en reposo o terminal, y registre identificador del servidor, timestamp y respuesta completa.
  5. Consuma eventos ordenados de ordenes y ejecuciones; concilie ejecucion acumulada, cantidad restante, identificador, precio, nocional, indicador de liquidez, moneda de comision o rebate y toda modificacion que altere la cola.
  6. Trate modificacion, cancelacion y sustitucion como carreras hasta recibir eventos terminales; reintente de forma idempotente tras timeouts y resincronice despues de mensajes duplicados, ausentes o desordenados.
  7. Concilie cantidades ejecutadas, canceladas, rechazadas o vencidas con inventario, retenciones y saldos; evalue comisiones, rebates, seleccion adversa y ejecuciones perdidas reales. En un centro onchain, verifique aparte inclusion, ejecucion del protocolo y finalidad exigida.

Ejemplos

  • Comportamiento al cruzar. El mejor bid y ask son 99.90 / 100.00 y el tick es 0.01. Una compra post-only de 2 BTC at 100.00 encontraria de inmediato el ask. Un centro de tipo reject rechaza la solicitud; uno de tipo cancel no registra ejecucion y la cancela. Uno de tipo reprice podria moverla a 99.99, pero solo si se solicito ese comportamiento documentado. Una compra a 99.99 puede quedar en el libro si el estado del motor no cambia; no se garantiza su ejecucion.
  • Ejecucion maker en reposo y comisiones. Una venta de 3 ETH at 99.90 queda en el libro con bid y ask en 99.80 / 100.00, y luego la ejecuta una compra agresiva. El nocional es 3 x 99.90 = 299.70. Con tasa maker de -1 bp, la comision es 299.70 x -0.0001 = -0.02997, es decir, un rebate. Clasificarla por error con tasa taker de 5 bp genera un cargo de 0.14985, una diferencia de 0.17982. Use el indicador de liquidez y el registro de comisiones reales.
  • Ejecucion parcial y carrera de cancelacion. Una venta post-only en reposo es de 10 units at 100. Se ejecutan 4 y el cliente envia la cancelacion. Antes de la cancelacion terminal se ejecuta otra 1, por lo que quedan 5 canceladas. La cantidad total ejecutada es 5, no 4; el nocional ejecutado es 500 y un rebate de 2 bp equivale a 0.10. Un acuse de cancelacion no es el registro terminal del inventario.
  • Menores comisiones aun pueden costar mas. Comprar 10 de inmediato a 100.00 con una comision taker de 8 bp cuesta 1,000.80. Perder ese precio y quedar despues en el libro a 100.20 con una comision maker de 2 bp cuesta 1,002.2004. La ruta maker ahorra 0.5996 en comisiones, pero cuesta 1.4004 mas en total. Post-only gestiona el comportamiento de ejecucion; no optimiza automaticamente la operacion completa.

Riesgos

  • Se presupone la regla post-only del centro o producto equivocado.
  • Una orden ejecutable se rechaza, cancela o ajusta de forma inesperada.
  • La latencia hace que un precio no cruzado en el cliente cruce al llegar al motor.
  • El redondeo al tick modifica el precio enviado o la prueba de cruce.
  • Un libro bloqueado, una subasta o un modo especial modifica el comportamiento.
  • Una orden en reposo nunca se ejecuta.
  • La seleccion adversa supera cualquier rebate maker.
  • Cambian el nivel, el signo del rebate o la moneda de comision.
  • Se infiere el estado maker de la solicitud y no de cada ejecucion.
  • Se subestiman la profundidad en cola o la liquidez oculta.
  • Una modificacion reinicia la prioridad en cola.
  • Se omite una ejecucion parcial del inventario o de la caja.
  • Una carrera de cancelacion o sustitucion crea otra ejecucion u orden solapada.
  • Un timeout o reintento no idempotente crea un estado incierto o duplicado.
  • Huecos, duplicados o desorden en WebSocket corrompen la vista local.
  • La prevencion de autonegociacion cancela o reduce un lado inesperado.
  • Post-only entra en conflicto con IOC, FOK u otra regla de vigencia.
  • Reduce-only, close-only o el modo de posicion rechaza, reduce o invierte la intencion.
  • Una orden hija activada pasa a ser ejecutable y se cancela o rechaza.
  • Un fallo del centro, custodia, API o reglas, o la ordenacion onchain, el gas, una reorganizacion o la finalidad, impide la conciliacion.

Errores comunes

  • Post-only garantiza una ejecucion. Puede rechazarse, cancelarse, quedar sin negociar o vencer.
  • Una respuesta correcta de la API prueba que la orden esta en el libro. El acuse de transporte y el estado del motor son registros distintos.
  • Cada ejecucion post-only obtiene un rebate. La clasificacion maker, el nivel, la moneda y la tasa dependen de cada ejecucion y centro.
  • Modificar o cancelar evita toda ejecucion posterior. Puede perderse prioridad y una ejecucion puede ganar la carrera antes de la confirmacion terminal.
  • Un hash de transaccion o la inclusion en un bloque prueba que una orden onchain aporto liquidez maker y se negocio con finalidad. Inclusion, ejecucion del protocolo, estado en reposo, ejecucion y finalidad de cadena son eventos distintos.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...