#termmax Al desglosar en profundidad el funcionamiento de TermMax V2, debemos enfrentarnos a una funcionalidad extremadamente peligrosa: permitir que los usuarios publiquen órdenes Limit (órdenes con precio límite) en todo el mercado. A primera vista, esto parece entregar el poder de fijar precios al usuario, pero muchos no lo entienden: en una red descentralizada de blockchain totalmente pública y transparente, publicar una orden límite equivale a entregar a los árbitros (traders de arbitraje) de toda la red una “opción gratuita”.
Cuando el mercado está estable, tus órdenes permanecen tranquilamente en el contrato esperando ser emparejadas; pero cuando sobreviene un escenario de volatilidad extrema y el precio del activo subyacente sufre una caída en cuestión de segundos, debes retirar la orden antes que los robots de MEV (valor extraíble por mineros). En ese momento, el cuello de botella de la estrategia del sistema deja de estar en la profundidad del pool de órdenes y pasa a depender de la velocidad de respuesta de los nodos RPC subyacentes y de la latencia de sincronización del estado del contrato inteligente.
Si, en un estado de alta concurrencia, la red subyacente se congestiona, tu solicitud de retirar la orden quedará trabada en el mempool durante incluso solo unos pocos segundos; entonces, esa orden con precio límite que originalmente estaba destinada a ganar un interés fijo será detectada con precisión por robots de arbitraje con una potencia de cómputo enorme, y será “comida” de forma forzada como si fueran simples fichas baratas, provocándote inmediatamente una pérdida enorme en el mercado spot.
Mi conclusión: si se ofrece la funcionalidad de órdenes con precio límite, se debe contar con una infraestructura de cancelación ultrarrápida que esté a la altura y con protecciones a nivel de capa base contra el acoso de MEV. Si el sistema no puede garantizar la confirmación en segundos de las órdenes de cancelación bajo una presión extrema de la red, estos Limit Orders publicados en el libro de contabilidad en cadena se convierten en una máquina expendedora automática para los árbitros de alta frecuencia. Si la defensa a nivel de red del ejecutor no está a la altura, incluso los tipos de órdenes más vistosos solo acelerarán la caída de los usuarios reales. @TermMax
Cuando el mercado está estable, tus órdenes permanecen tranquilamente en el contrato esperando ser emparejadas; pero cuando sobreviene un escenario de volatilidad extrema y el precio del activo subyacente sufre una caída en cuestión de segundos, debes retirar la orden antes que los robots de MEV (valor extraíble por mineros). En ese momento, el cuello de botella de la estrategia del sistema deja de estar en la profundidad del pool de órdenes y pasa a depender de la velocidad de respuesta de los nodos RPC subyacentes y de la latencia de sincronización del estado del contrato inteligente.
Si, en un estado de alta concurrencia, la red subyacente se congestiona, tu solicitud de retirar la orden quedará trabada en el mempool durante incluso solo unos pocos segundos; entonces, esa orden con precio límite que originalmente estaba destinada a ganar un interés fijo será detectada con precisión por robots de arbitraje con una potencia de cómputo enorme, y será “comida” de forma forzada como si fueran simples fichas baratas, provocándote inmediatamente una pérdida enorme en el mercado spot.
Mi conclusión: si se ofrece la funcionalidad de órdenes con precio límite, se debe contar con una infraestructura de cancelación ultrarrápida que esté a la altura y con protecciones a nivel de capa base contra el acoso de MEV. Si el sistema no puede garantizar la confirmación en segundos de las órdenes de cancelación bajo una presión extrema de la red, estos Limit Orders publicados en el libro de contabilidad en cadena se convierten en una máquina expendedora automática para los árbitros de alta frecuencia. Si la defensa a nivel de red del ejecutor no está a la altura, incluso los tipos de órdenes más vistosos solo acelerarán la caída de los usuarios reales. @TermMax