¡La humanidad no ha desarrollado Codex ni el 1%!
Ayer recién conseguí la API y le dediqué un poco de tiempo a hacer un script para colgar órdenes
Activos totales iniciales de la cuenta: 311.8u
Corrí toda la noche y alcancé un volumen de operaciones de 8k; además gané 1.31u
El coste en puntos de algo así es equivalente a negativo
Principalmente porque la liquidez de la plataforma ahora está buenísima
Para hacer un script como este hay muchas cosas que tener en cuenta:
- ¿Qué tareas pueden ejecutarse en paralelo y cuáles acciones deben ir en serie?
La lectura puede ir en paralelo, pero lo ideal es que la colocación de órdenes y la cancelación sean secuenciales; si no, es muy fácil que otro hilo elimine o cancele por error una orden que acaba de publicarse, o que se publiquen órdenes duplicadas
- ¿Conviene dividir hilos para BUY y SELL?
BUY necesita revisar el mercado y el libro de órdenes, es relativamente lento; SELL necesita vigilar las posiciones de la cuenta y responder rápido. Al separarlos, SELL no queda bloqueado por el escaneo completo de BUY
- ¿Cómo diseñar el state local?
No se puede depender solo de las open orders de la API, porque el estado del exchange no es consistente en tiempo real. Después de que create order sea exitoso, las open orders pueden tardar unos segundos en aparecer al consultarlas. El state local necesita encargarse de la deduplicación a corto plazo, evitar enviar repetidos y prevenir una limpieza accidental
- ¿Cómo manejar la consistencia eventual?
Una orden recién creada no debe considerarse inválida solo porque en el siguiente segundo no aparezca en open orders. Hay que establecer una ventana de espera, por ejemplo 30-60 segundos, para evitar que el hilo de sincronización de la cuenta elimine por error una orden nueva
- ¿Cómo obtener el precio de la orden?
Yes / No, Over / Under y resultados inversos se pueden calcular fácilmente de forma errónea. Especialmente en SELL, lo mejor es usar el bestAsk del outcome actual de la posición, en lugar de tomar ciegamente el lado Yes del orderbook como complemento
- ¿Cómo manejar la precisión de las participaciones?
En la interfaz se muestra 17.86, pero eso no significa que 17.86 sea exactamente lo que se puede vender. La cantidad de orden debe truncarse hacia abajo; no se debe redondear, porque si no se puede terminar con insufficient shares
- ¿Cómo clasificar las excepciones de la API?
hash mismatch, saldo insuficiente, participaciones insuficientes, desconexión del extremo remoto, respuesta truncada, retraso en la sincronización de órdenes: la forma de tratarlas es distinta. No se puede hacer un retry infinito y simple
- ¿Cómo escribir los límites de control de riesgos?
No vender a mercado, no tomar órdenes (no eat), post-only, limitar el rango de BUY y cancelar las órdenes de compra antes de que empiece la competición: todo esto tiene que convertirse en restricciones “duras” en el código
No es que con IA se pueda hacer fácilmente un sistema estable y entregable a largo plazo; necesariamente hay que enfocarse desde la ingeniería y hacer pruebas de estabilidad y control de riesgos
¡Interesados, vengan a intercambiar～
@Predictdotfun
Ayer recién conseguí la API y le dediqué un poco de tiempo a hacer un script para colgar órdenes
Activos totales iniciales de la cuenta: 311.8u
Corrí toda la noche y alcancé un volumen de operaciones de 8k; además gané 1.31u
El coste en puntos de algo así es equivalente a negativo
Principalmente porque la liquidez de la plataforma ahora está buenísima
Para hacer un script como este hay muchas cosas que tener en cuenta:
- ¿Qué tareas pueden ejecutarse en paralelo y cuáles acciones deben ir en serie?
La lectura puede ir en paralelo, pero lo ideal es que la colocación de órdenes y la cancelación sean secuenciales; si no, es muy fácil que otro hilo elimine o cancele por error una orden que acaba de publicarse, o que se publiquen órdenes duplicadas
- ¿Conviene dividir hilos para BUY y SELL?
BUY necesita revisar el mercado y el libro de órdenes, es relativamente lento; SELL necesita vigilar las posiciones de la cuenta y responder rápido. Al separarlos, SELL no queda bloqueado por el escaneo completo de BUY
- ¿Cómo diseñar el state local?
No se puede depender solo de las open orders de la API, porque el estado del exchange no es consistente en tiempo real. Después de que create order sea exitoso, las open orders pueden tardar unos segundos en aparecer al consultarlas. El state local necesita encargarse de la deduplicación a corto plazo, evitar enviar repetidos y prevenir una limpieza accidental
- ¿Cómo manejar la consistencia eventual?
Una orden recién creada no debe considerarse inválida solo porque en el siguiente segundo no aparezca en open orders. Hay que establecer una ventana de espera, por ejemplo 30-60 segundos, para evitar que el hilo de sincronización de la cuenta elimine por error una orden nueva
- ¿Cómo obtener el precio de la orden?
Yes / No, Over / Under y resultados inversos se pueden calcular fácilmente de forma errónea. Especialmente en SELL, lo mejor es usar el bestAsk del outcome actual de la posición, en lugar de tomar ciegamente el lado Yes del orderbook como complemento
- ¿Cómo manejar la precisión de las participaciones?
En la interfaz se muestra 17.86, pero eso no significa que 17.86 sea exactamente lo que se puede vender. La cantidad de orden debe truncarse hacia abajo; no se debe redondear, porque si no se puede terminar con insufficient shares
- ¿Cómo clasificar las excepciones de la API?
hash mismatch, saldo insuficiente, participaciones insuficientes, desconexión del extremo remoto, respuesta truncada, retraso en la sincronización de órdenes: la forma de tratarlas es distinta. No se puede hacer un retry infinito y simple
- ¿Cómo escribir los límites de control de riesgos?
No vender a mercado, no tomar órdenes (no eat), post-only, limitar el rango de BUY y cancelar las órdenes de compra antes de que empiece la competición: todo esto tiene que convertirse en restricciones “duras” en el código
No es que con IA se pueda hacer fácilmente un sistema estable y entregable a largo plazo; necesariamente hay que enfocarse desde la ingeniería y hacer pruebas de estabilidad y control de riesgos
¡Interesados, vengan a intercambiar～
@Predictdotfun
