#dusk $DUSK Últimamente empecé a hacer trading con robots. El estado más desesperante que me he encontrado es este: la interfaz se queda mostrando “Connected”, pero la consulta no obtiene respuesta durante mucho tiempo, y el robot sigue esperando tonto en esa misma conexión.
En el repositorio oficial de Dusk Rusk hay un issue de integración: W3sper comprueba si la red está en línea, principalmente mirando si la conexión WebSocket de la propia máquina sigue en estado OPEN. Puedes entenderlo como que la llamada no se ha colgado todavía. Pero cuando el enlace está medio cortado, el ícono de llamada permanece encendido aunque del otro lado ya no pueden oírte. Su mecanismo de keep-alive solo envía mensajes periódicamente hacia afuera; no confirma que el otro realmente haya respondido.
Esto arrastra la operación a un agujero oculto: no se puede leer el saldo, no se puede enviar el stop loss, las cotizaciones se quedan congeladas en el precio antiguo y el inventario tampoco se puede ajustar. Lo peor es que el sistema sigue considerando que el nodo principal “está en línea”, y el nodo de respaldo tarda mucho en tomar el relevo.
En ese momento puedes mirar la cadena y parecer que está bien, pero la posición ya ha perdido su salida.
Al principio lo tomé como un fallo pequeño en el SDK. Pero cuando metes el riesgo de la posición en los cálculos, me empecé a poner nervioso. Cuánto capital asigna una institución a una cadena se traduce directamente en: cuánto tiempo tarda en detectarse la falla, cuánto tarda la línea de respaldo en reconectarse y, en el peor caso, cuánto tiempo puede quedar el dinero atrapado. Que la respuesta sea rápida unos pocos milisegundos, en promedio, en realidad no pesa tanto.
Por eso, el “porcentaje de disponibilidad” de Dusk no debería basarse solo en un estado verde. Que la última solicitud haya recibido respuesta, cuántas veces seguidas se superaron los tiempos de espera, cuánto tardó el cambio en el 5% más lento y cuántas veces el nodo de respaldo asumió con éxito la operación: esos datos se acercan mucho más a la experiencia real del trading.
Creo que esto también afecta la valoración de $DUSK . Si se asume “online”, el trading puede quedarse trabado en la capa del SDK: en la cadena se ve como que disminuyen las comisiones y el número de transacciones; pero para una institución puede significar que reduzca el inventario que mantiene fijo y deje una porción más de capital como respaldo. Si no se puede dejar el dinero mucho tiempo en la cadena, las operaciones repetidas y la demanda de Gas naturalmente se vuelven más débiles.
El TPS nos dice qué tan rápido puede correr la cadena. La capacidad de conmutación en fallas determina si, en el peor escenario del mercado, el dinero todavía puede salir. ¿No es acaso esa la experiencia de trading que más valora cualquiera, cualquier institución?
@Dusk
$BTC
En el repositorio oficial de Dusk Rusk hay un issue de integración: W3sper comprueba si la red está en línea, principalmente mirando si la conexión WebSocket de la propia máquina sigue en estado OPEN. Puedes entenderlo como que la llamada no se ha colgado todavía. Pero cuando el enlace está medio cortado, el ícono de llamada permanece encendido aunque del otro lado ya no pueden oírte. Su mecanismo de keep-alive solo envía mensajes periódicamente hacia afuera; no confirma que el otro realmente haya respondido.
Esto arrastra la operación a un agujero oculto: no se puede leer el saldo, no se puede enviar el stop loss, las cotizaciones se quedan congeladas en el precio antiguo y el inventario tampoco se puede ajustar. Lo peor es que el sistema sigue considerando que el nodo principal “está en línea”, y el nodo de respaldo tarda mucho en tomar el relevo.
En ese momento puedes mirar la cadena y parecer que está bien, pero la posición ya ha perdido su salida.
Al principio lo tomé como un fallo pequeño en el SDK. Pero cuando metes el riesgo de la posición en los cálculos, me empecé a poner nervioso. Cuánto capital asigna una institución a una cadena se traduce directamente en: cuánto tiempo tarda en detectarse la falla, cuánto tarda la línea de respaldo en reconectarse y, en el peor caso, cuánto tiempo puede quedar el dinero atrapado. Que la respuesta sea rápida unos pocos milisegundos, en promedio, en realidad no pesa tanto.
Por eso, el “porcentaje de disponibilidad” de Dusk no debería basarse solo en un estado verde. Que la última solicitud haya recibido respuesta, cuántas veces seguidas se superaron los tiempos de espera, cuánto tardó el cambio en el 5% más lento y cuántas veces el nodo de respaldo asumió con éxito la operación: esos datos se acercan mucho más a la experiencia real del trading.
Creo que esto también afecta la valoración de $DUSK . Si se asume “online”, el trading puede quedarse trabado en la capa del SDK: en la cadena se ve como que disminuyen las comisiones y el número de transacciones; pero para una institución puede significar que reduzca el inventario que mantiene fijo y deje una porción más de capital como respaldo. Si no se puede dejar el dinero mucho tiempo en la cadena, las operaciones repetidas y la demanda de Gas naturalmente se vuelven más débiles.
El TPS nos dice qué tan rápido puede correr la cadena. La capacidad de conmutación en fallas determina si, en el peor escenario del mercado, el dinero todavía puede salir. ¿No es acaso esa la experiencia de trading que más valora cualquiera, cualquier institución?
@Dusk
$BTC