Polius2007

Construyo software para traders de cripto: XTester Studio para investigación de estrategias y backtesting, y CopyTrader para traders que quieren ofrecer copiado de operaciones a su propia audiencia.

Aquí compartiré en qué estoy trabajando, los experimentos detrás de ello y las decisiones de producto a lo largo del camino. Eso incluye cómo probar una idea de estrategia, qué puede decirte un backtest y el trabajo práctico de construir un servicio de copy-trading.

Si investigas estrategias o diriges una comunidad de trading, me gustaría saber qué es lo que más tiempo consume en tu flujo de trabajo.

Mis proyectos: https://easytrading.pw

#Backtesting #CopyTrading

OKXICE's upcoming tokenized-stock venue plans to show the estimated dollar gap between a stock's reference value and the result of a proposed swap. I'd judge the quote against that reference before signing.

For a purchase, the proposed confirmation screen would show the minimum number of share tokens received. For a sale, it would show the minimum stablecoins received. These are the amounts the transaction must meet to execute. A swap outside the chosen slippage tolerance would fail, though network fees could still be charged.

The October 4 public notice explains why the stock valuation remains a separate comparison. Stock-market data supplies the dollar value displayed in the interface. The swap would execute against a liquidity pool whose asset balances set the price, without an outside stock-price feed controlling execution. The notice specifically flags possible divergence outside the stock exchange's regular hours.

A tighter slippage setting can reject a worse swap, but it cannot pull the pool's quote toward the stock market's price. The estimated dollar gap is what lets the trader judge that quote against the shares' reference value before accepting it.

Source: https://www.okx.com/cdn/assets/files/2610/FA22FC62E8823382.pdf

If your OKX bot's connection address still contains :8443, there's a deadline for changing it: October 31.

OKX's September 30 notice retires that port for WebSocket connections, which carry continuous market and account updates. Port 443 already works. The published change is simply to remove :8443, leaving the rest of the address alone. Both live and demo trading connections are affected.

I'd make the switch while both routes are available, rather than leave the first connection attempt until the old one closes. For anyone using a third-party bot, this is a specific question for its operator: has the OKX connection moved off 8443?

REST, the separate request-based interface many integrations use for orders, is unaffected. A bot using REST for orders and the old WebSocket address for updates needs the connection change even though its order interface isn't being retired.

Source: https://www.okx.com/en-eu/help/okx-websocket-port-8443-discontinuation-announcement

Kraken's new Pre-IPO Challenge ranks traders by volume, not profit.

The October 6 announcement sets a $10,000 minimum in combined trading volume across the OURAx and MOONSHOTx perpetual futures to appear on the leaderboard. Higher volume earns a higher rank, with prizes determined by the final standings. The competition runs through November 6.

A trader can lose money and still finish near the top by generating enough qualifying volume. For someone considering copying that trader, the missing information is the trading result: how much they made or lost to produce that turnover.

Source: https://blog.kraken.com/product/promotions/the-pre-ipo-challenge-ourax-and-moonshotx/

Para una mesa de operaciones que mueve efectivo de una operación a la siguiente, el nuevo programa de liquidación de Solana tiene un detalle útil: el efectivo pasa a una cuenta de depósito en garantía antes de que se liquide la operación.

La Fundación Solana anunció Solana DvP el 6 de octubre. Permite que dos partes intercambien un activo y el pago en una sola transacción, de modo que ambas transferencias se realizan al mismo tiempo o no se realiza ninguna.

El diseño publicado separa ese intercambio final de la preparación. Tanto el comprador como el vendedor depositan fondos en una cuenta de depósito en garantía. Luego, una autoridad de liquidación designada presenta la liquidación. Depositar el dinero no completa la operación por sí solo.

Cualquier espera entre el depósito de fondos y la liquidación mantiene inmovilizado el efectivo del comprador. Mientras está en la cuenta de depósito en garantía, el comprador no puede usarlo para otra compra. Puede solicitar que se lo devuelvan antes de la liquidación, pero eso retira el dinero de esta operación.

Para una mesa que compara vías de liquidación, la medición útil empieza cuando se compromete el dinero, no solo cuando se presenta la transacción de liquidación. La afirmación del anuncio de que la «finalidad se alcanza en segundos» describe el último paso; el momento en que la mesa debe financiar la operación determina cuánto tiempo queda inmovilizado su efectivo.

Fuentes:
https://solana.com/news/solana-foundation-launches-solana-dv-p-an-atomic-settlement-program-built-for-financial-institutions
https://github.com/solana-foundation/dvp

Las páginas oficiales de Glamsterdam de Ethereum ofrecen actualmente dos respuestas distintas sobre cómo abaratar las transferencias de ETH.

La página de la hoja de ruta afirma que la EIP-2780 abarataría hasta un 71 % una transferencia estándar entre cuentas existentes. Sin embargo, al abrir la propuesta, su texto actual mantiene explícitamente en 21.000 unidades de gas de ejecución una transferencia simple de ETH a una cuenta existente.

Ahora, la propuesta desglosa el coste en componentes: procesar al remitente, acceder al destinatario y transferir el valor. Crear una cuenta nueva añade un cargo aparte por los datos permanentes que genera. Esto hace que el estado de la cuenta del destinatario sea relevante para el requisito de gas de la transferencia, incluso cuando no hay ningún intercambio de tokens ni otra interacción con un contrato.

La consecuencia práctica es más limitada que una reducción generalizada de las comisiones. La propuesta actual no permite calcular que una transferencia normal de ETH supondrá un ahorro del 71 %. Tampoco predice el precio del gas que pagarás.

El anuncio de la testnet de Glamsterdam deja sin decidir cuándo llegará a la red principal. Hasta que se finalicen las reglas, los ejemplos de transacciones de la propuesta son más útiles para estimar qué cambiará que el porcentaje que aún aparece en la página de resumen.

Fuentes:
https://ethereum.org/roadmap/glamsterdam/
https://eips.ethereum.org/EIPS/eip-2780
https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement

No tienes que usar un puente tú mismo para acabar teniendo un token puenteado.

Si un intercambio en X Layer te paga en USDC.e, has recibido un activo puenteado sin mover tu billetera a otra red. Circle incluye allí un contrato independiente para el USDC nativo y afirma explícitamente que USDC.e no es emitido ni respaldado por Circle.

Eso no significa que el USDC puenteado carezca de garantía. Circle describe el modelo general como un token de un tercero respaldado por USDC bloqueado en un contrato inteligente en otra cadena de bloques. El puente sigue formando parte del acuerdo mientras tengas el token.

Si los fondos obtenidos esperan entre operaciones, la diferencia persiste tras la venta. Has vendido la moneda original, pero elegir el token puenteado también implica confiar en ese puente. El directorio de contratos de la red principal de Circle te permite comprobar si el activo recibido es su USDC nativo; permanecer en la misma red no responde a esa pregunta.

Fuentes:
https://developers.circle.com/stablecoins/usdc-contract-addresses
https://www.circle.com/bridged-usdc

Cuando un bot espera a que se ejecute una orden antes de enviar la siguiente, hay un intervalo que vale la pena analizar: la primera orden ya se ejecutó, pero el bot aún no se ha enterado.

Esto puede ocurrir en una conexión que consulta periódicamente las actualizaciones de las órdenes. Hasta que la siguiente consulta informa de que la orden se ejecutó, la segunda orden no se envía. Una actualización inmediata en un backtest permitiría al bot enviarla antes, incluso con exactamente las mismas reglas de trading.

En la versión de desarrollo del backtester XTester en el que estoy trabajando, un modo opcional retiene esas actualizaciones hasta la siguiente consulta. Así se simula la espera para recibir la notificación de que una orden se ejecutó, en lugar de retrasar la ejecución en sí. Las respuestas a las propias solicitudes del bot no se retienen de la misma manera.

Para este tipo de estrategia, la comparación plantea una pregunta concreta: ¿cuándo se envió la segunda orden? Así se detecta cualquier ventaja inicial creada por una notificación inmediata.

En el conversor de estrategias en el que estoy trabajando, una revisión de una estrategia compleja detectó que los indicadores de volumen se habían sustituido por indicadores de precio. También señaló que el dimensionamiento de las posiciones eludía el componente previsto para ello.

Esos hallazgos requieren que el operador tome una decisión. Una regla que usa el volumen y otra que usa el precio analizan información de mercado diferente. Por otra parte, cambiar la forma de calcular el tamaño de las órdenes puede modificar la exposición, aunque la señal se mantenga intacta.

Aun así, un backtest de esa adaptación podría ser útil. Describiría la estrategia resultante de la traducción, incluidas sus sustituciones. No demostraría cómo habría funcionado la estrategia original. El informe de conversión debe mostrar claramente esos cambios para que el operador pueda decidir si los acepta o si hay que corregirlos.

Estoy desarrollando un simulador de carteras en el que varias estrategias operan con una sola cuenta. La forma de dividir el dinero cambia qué órdenes acepta la prueba.

Asigna 6.000 USDT a una estrategia y 400 a otra. En una prueba de desarrollo, se aceptó una compra por valor de 500 para la primera y se rechazó para la segunda. Había suficiente dinero en la cartera, pero la estrategia con menos fondos no podía tomar prestada la asignación de la otra.

Un fondo común mantiene compartidos los fondos disponibles de la cuenta. Los presupuestos asignados imponen un límite adicional a lo que puede usar cada estrategia. Una comparación de carteras debe preservar esa distinción: cambiar la regla de asignación puede cambiar qué órdenes cumplen los requisitos, aunque las reglas de entrada y salida sigan siendo las mismas.

En el modelo de cuenta compartida que estoy desarrollando, esos presupuestos siguen compartiendo el margen y la liquidación de la cuenta. Ni siquiera un presupuesto de estrategia sin usar puede hacer que una nueva compra sea asequible cuando la cuenta se ha quedado sin fondos disponibles. Dividir el dinero en un informe no le da a cada estrategia una cuenta independiente.

Ya estoy en Singapur para TOKEN2049. Mi primera foto desde aquí, con Marina Bay Sands asomando entre los edificios.

Estoy aquí como desarrollador de XTester y CopyTrader. Si creas herramientas de trading, trabajas con exchanges o gestionas estrategias de trading, tendremos mucho de qué hablar.

Si tú también estás en Singapur, quedemos. Cuéntame en qué estás trabajando.

#TOKEN2049

Si estuviera construyendo una estrategia en torno a “comprar después de un cierre diario por encima de una resistencia”, necesitaría saber cuándo termina ese día.

Una vela construida alrededor de la medianoche UTC y otra construida alrededor de la medianoche UTC+8 recogen porciones diferentes del mismo mercado. Un rally puede terminar dentro de la vela de un día y extenderse hasta el siguiente en la otra gráfica. La última operación en cada ventana puede ser distinta, por lo que un cierre diario puede superar un nivel fijo de resistencia mientras que el otro se mantiene por debajo.

Binance Spot admite ambas formas de construir velas diarias. UTC es la opción predeterminada; una zona horaria de vela diferente cambia los propios intervalos. Solo cambiar la etiqueta del reloj debajo de una gráfica existente no lograría eso.

Eso hace que la hora de cierre forme parte de la regla de entrada de una estrategia diaria. Determina tanto el precio que se está probando como el momento en que la señal queda disponible. Un backtest construido con días en UTC y una alerta construida con días en UTC+8 pueden discrepar sin que ninguno tenga precios malos. Hacer coincidir la moneda y la etiqueta “1D” aún deja esa parte de la regla sin especificar.

Di una estrategia que compra la moneda con la mayor ganancia con respecto a la semana anterior. Para volver a reproducir esa elección, cada mercado elegible en esa fecha tiene que permitirse en el ranking, incluidas las operaciones que desde entonces han desaparecido del exchange.

Empieza con la lista de hoy, y un antiguo contendiente podría no llegar a considerarse nunca. Su historial de precios podría estar disponible y ser perfectamente preciso. Aun así, la regla no puede elegirlo si no está en la lista. Las monedas que aparecen listadas más tarde tienen el problema opuesto: deben esperar a que estuvieran realmente disponibles en ese venue.

Aquí es donde yo separaría dos experimentos. Probar un conjunto elegido de monedas es una pregunta razonable por sí misma. Probar si una regla podría haber seleccionado ese conjunto hace años requiere evidencia de qué mercados eran elegibles en cada fecha de selección. Un directorio de mercados actual no aporta ese historial; Bybit describe su búsqueda spot como devolviendo símbolos de Trading.

Sin la pertenencia fechada, el resultado pertenece al conjunto elegido. No establece qué monedas habría elegido la regla a partir de los mercados disponibles entonces.

Cuando un libro de órdenes registrado no explica una operación, primero querría saber qué se estaba registrando.

Bybit tiene dos capturas diferentes que conviene distinguir. La estándar omite las órdenes de Retail Price Improvement, una clase distinta de órdenes en la bolsa. La otra informa su tamaño junto con las órdenes habituales. Guardar más niveles de precio de la primera captura no la convierte en la segunda.

Para alguien que reproduce un mercado, eso cambia la investigación. Antes de ajustar los llenos simulados para que coincidan con una operación real, comprueba si la grabación incluye el tipo de órdenes que estás intentando contabilizar.

La captura separada también tiene exclusiones, así que no es un registro completo de cada orden. Ninguna de las dos capturas, por sí sola, te dice por qué se llenó una operación en particular ni si tu orden podría haber coincidido con esas cotizaciones. Pero consultar la fuente te indica qué categorías de órdenes tu reproducción podría ver en primer lugar.

Una orden cancelada aún puede haberle comprado algo.

La documentación de derivados de Bybit hace una distinción pequeña pero importante: una orden marcada como Cancelada puede ya haber ejecutado cierta cantidad. La cancelación te dice que la orden dejó de funcionar. No te dice que no pasó nada antes de que se detuviera.

Supongamos que envías una orden para comprar diez contratos, se completan tres, y el resto se cancela. Enviar otra orden por diez llevaría el total a trece si se completa por completo. La intención original era diez.

Por eso leería la cantidad ejecutada antes de decidir qué reenviar. El estado final de una orden y la cantidad realmente negociada responden preguntas distintas. Tratar Cancelada como una pizarra en blanco puede convertir un reintento en una operación más grande.

Dos pantallas de trading pueden mostrar la misma tasa de financiación y aun así dejarte con facturas muy diferentes.

En los futuros perpetuos, la financiación es un pago periódico entre traders que mantienen posiciones opuestas en el mercado. El porcentaje va acompañado de un reloj. La documentación de Bybit indica explícitamente que el intervalo difiere entre contratos.

Veamos un ejemplo sencillo: una posición de $10,000 que paga 0.01% en cada liquidación. Eso son $1 por pago. A lo largo de un día completo, un intervalo de ocho horas significa tres pagos, o $3. Un intervalo de una hora significa 24 pagos, o $24. Esto asume que el valor de la posición y la tasa se mantienen sin cambios y que la estás manteniendo en cada liquidación. Es una ilustración, no una previsión.

Yo querría que el intervalo aparezca junto al porcentaje al comparar mercados. Una tasa que parece más pequeña aun puede costar más en el tiempo que planeo mantener la operación. Comparar solo las tasas deja fuera el número de pagos en la factura.

Un mercado spot que tenga USDC en su nombre aún puede permitirte operar con USD. Esa distinción importa si tu bot usaba los mercados spot de USD afectados de OKX.

La actualización de OKX del 30 de septiembre indica que esos mercados se han movido a los nombres correspondientes de USDC. Los nombres antiguos no redirigirán. Cambia solo el nombre del mercado en el bot; aun así, una orden que deja la divisa sin especificar ahora se predetermina a USDC.

Todavía puedes solicitar USD explícitamente cuando el mercado lo admite.

Yo verificaría la divisa de la orden por separado de su nombre de mercado antes de reiniciar. Que los precios vuelvan a aparecer no responderá esa pregunta: ¿la siguiente orden solicita USD, o ha caído silenciosamente de vuelta a USDC?

Le pedí que el botón Stop permaneciera deshabilitado hasta que el trader tomara una decisión.

Esto surgió mientras trabajaba en cómo se detienen los robots de trading en XTester Studio. Al detener el programa, aparece otra pregunta: ¿qué debería pasar con las órdenes y la posición que ya tiene en el exchange?

Quería que eso se respondiera de forma explícita, sin que se seleccione ninguna opción de antemano. Eliminar un robot también requiere una decisión separada sobre sus órdenes y su posición. Quitarlo de una lista no responde ninguna de las dos preguntas.

Había un detalle que quería precisar: si el trader decide dejar todo en su lugar, el código de apagado de la estrategia no debe enviar nuevas órdenes al salir. De lo contrario, el programa podría cambiar justamente las cosas que el trader le había pedido que dejara en paz.

El diálogo de detención y esa restricción se unifican y se prueban. La aceptación del trading en vivo aún está pendiente.

Un botón con la etiqueta Stop parece sencillo. Decidir exactamente qué es lo que detiene requirió más trabajo.

Mi gráfico sabía cómo terminaría 2019. La repetición todavía estaba en marzo.

Durante el trabajo en XTester Studio, la vela anual ya mostraba el máximo y el cierre de todo el año. El gráfico mensual se veía bien, lo que hacía que la diferencia valiera la pena investigarla.

El gráfico había cargado su historial antes de que comenzara la repetición y mantenía esa ventana en memoria. Al iniciar la repetición, se ocultaron las velas que pertenecían completamente al futuro, pero la vela del año en curso permaneció allí, completa. El motor de simulación estaba cortando los datos en la fecha correcta. El gráfico estaba mostrando una vista antigua y sin restricciones.

El gráfico mensual se había abierto después de que comenzara la repetición. Esa pequeña diferencia en cuándo se abrió el gráfico explicaba por qué ambos se veían distintos.

La corrección y las pruebas de regresión ya están fusionadas. Verificar el comportamiento en una compilación ejecutándose de forma nueva todavía está en la lista.

Para cualquiera que practique con gráficos históricos, este es un tipo incómodo de fallo: una vela puede estar en la fecha correcta y aun así contener precios que no deberías haber visto todavía.