pitRobinhood Chain
TRANSPARENCIA POR DISEÑO

Cada resultado tiene historia.

La clasificación se construye con observaciones y decisiones guardadas. Puedes descargar las rondas ya publicadas y comprobar cómo hemos llegado a cada resultado.

Dos modos, claramente separados

Robinhood: operaciones virtuales sobre precios de pools de Robinhood Chain obtenidos de GeckoTerminal, con DEX Screener como respaldo. No se envían transacciones a la blockchain.

Demo: un escenario sintético reproducible de 24 horas, con nombres de activos ilustrativos. Usa el mismo motor y las mismas reglas, pero sus precios, liquidez y resultados son inventados para mostrar el funcionamiento. Nunca se suma a las métricas de rentabilidad de una temporada real.

Fuentes y selección

Consultamos la lista de pools de Robinhood en GeckoTerminal. Elegimos hasta diez activos, excluimos símbolos habituales de stablecoins y conservamos el pool más líquido por dirección de token dentro de los resultados disponibles. No es una revisión exhaustiva de todos los activos de la chain.

El universo de pools queda fijo durante la temporada. Una nueva observación tiene que incluir al menos tres mercados válidos y superar los controles de antigüedad y liquidez. Si un activo deja de estar disponible se conserva su última valoración, marcada por la antigüedad de la observación, y no se ejecutan órdenes sobre ese mercado.

Si GeckoTerminal falla o no ofrece tres mercados válidos, consultamos DEX Screener una vez para los mismos pools. Solo aceptamos coincidencias de pool, contrato base y chain con señales completas. No invertimos pares ni sustituimos contratos. La fuente queda guardada en cada observación y se muestra en la tabla de mercados; los proveedores pueden discrepar en precios y ventanas de variación. Si el respaldo tampoco es válido, la ronda se aplaza.

Cadencia y marcas de tiempo

El intervalo mínimo entre observaciones es de 1 minuto. Cada agente puede mantener varias posiciones simultáneas; cada observación permite una nueva decisión por agente y no obliga a cerrar las anteriores. La competición termina en la fecha común de la temporada, no al cerrar una posición. La cuenta atrás usa la hora del servidor y solicita una nueva observación al llegar a cero; un pulso del navegador revisa las rondas pendientes mientras la página está visible. El piloto de GitHub Actions arranca una ventana cada 5 minutos y dentro de ella solicita observaciones cada minuto, respetando la próxima hora permitida por el servidor. Los arranques pueden retrasarse o perderse; no es una garantía de operación continua. Cualquiera de las dos vías usa el mismo motor y nunca puede modificar la estrategia o saltarse el intervalo.

Sin un proceso programado activo ni visitantes, la liga no avanza. Cuando vuelve a recibir datos registra una nueva observación, descarta órdenes caducadas y muestra los huecos temporales. La hora de recepción y la fecha HTTP de la fuente permiten detectar respuestas antiguas; no equivalen a la hora exacta de cada operación del DEX.

La versión original, pit-v1, usaba un intervalo mínimo de 15 minutos. pit-v1.1 usaba 3 minutos; pit-v1.2 usa 1 minuto. La primera ronda con la nueva cadencia incluye el cambio y su hora en el registro verificable, sin recalcular rondas anteriores. La descarga identifica las tres versiones de las reglas. Los resultados anteriores y posteriores corresponden a frecuencias distintas y no deben interpretarse como una prueba bajo una única cadencia fija.

Radar, señales y cobertura

El radar consulta la API pública de FomoRadar para mostrar compras compartidas, salidas, operaciones atribuidas a wallets y su clasificación. Las señales usan una ventana de seis horas y al menos dos wallets. Su convicción es la suma de (puntuación / 100)² de las wallets; no es una probabilidad de acierto. Las salidas cuentan reducciones de al menos la mitad de la posición observada.

La cinta muestra operaciones de wallets con puntuación de al menos 60 según FomoRadar. La fuente filtra la procedencia de las operaciones; PIT no revalida los recibos ni certifica esas puntuaciones. La API no proporciona hashes de transacción en la cinta: se deduplica por hora, token, dirección de operación, perfil e importe. Dos eventos indistinguibles pueden mostrarse como uno.

Una lectura compartida se actualiza como máximo cada 30 segundos mientras se consulta el radar. Si falla la fuente, conservamos la última lectura, su hora y un aviso. La animación inicial reproduce las últimas operaciones y lo indica; después representa únicamente nuevos eventos recibidos. Las órdenes pendientes de PIT nunca alimentan el radar.

GeckoTerminal y DEX Screener son fuentes de precios de la liga, no lugares donde PIT envíe órdenes. PonsFamily es un launchpad de Robinhood Chain; no integramos directamente todos sus lanzamientos ni sus curvas de precio. Un token procedente de Pons puede aparecer si está cubierto por nuestras fuentes. La liga se limita a sus diez pools iniciales; las señales de FomoRadar tienen un universo distinto y no se compran automáticamente.

Comparación de estrategias v2

El laboratorio inicia dos carteras por agente con 10.000 US$ virtuales en la primera observación recibida tras activar la comparación. Ambas ramas usan los mismos mercados, tiempos, comisiones, deslizamiento, gas, límites y ejecución en la ronda posterior. SURGE v2 exige confirmación de tendencia y volumen; CHAOS v2 exige ruptura y volumen. ECHO conserva sus reglas en las dos ramas y sirve como control de igualdad.

Las reglas v2 quedan identificadas por versión y documentadas en el laboratorio. Se acumulan datos hacia adelante, sin entrenamiento ni ajuste sobre resultados futuros y sin sustituir automáticamente a los agentes de la liga. El registro del experimento tiene su propia cadena de huellas y retrasa las rondas que contengan órdenes pendientes en cualquiera de sus dos ramas.

Detalle de las curvas

Las curvas conservan todas las observaciones de las últimas 24 horas y una muestra por tramo de 10 minutos para fechas anteriores, además del punto inicial. La clasificación, los costes y la caída máxima se calculan con todas las observaciones. El registro descargable conserva el historial completo, sin esta agrupación.

Publicación de las decisiones

Las órdenes se registran en privado antes de intentar ejecutarlas. Su activo, dirección, importe y explicación se publican cuando se han ejecutado o descartado. Las órdenes pendientes no se entregan al navegador ni aparecen en la API pública.

La descarga retrasa una ronda completa si contiene órdenes todavía pendientes y publica únicamente el tramo inicial resuelto del historial. Cuando todas esas órdenes se resuelven, la ronda se puede descargar con su contenido original. El estado «pending» dentro de un payload histórico describe el momento de su registro, no una orden aún disponible para ejecutar.

Registro verificable

Cada ronda contiene precios, decisiones, ejecuciones, la huella de la ronda anterior y su propia huella SHA-256. La descarga conserva el contenido exacto utilizado para calcular cada huella.

hash = SHA256(hash_anterior + salto_de_línea + payload)

Esto detecta cambios o huecos respecto a una copia que hayas conservado. El registro se almacena en la base de datos de Pit: no está anclado on-chain ni proporciona un sello temporal independiente. Un operador con acceso suficiente podría reescribir toda la cadena; conservar exportaciones permite contrastarlas.

Lo que el modelo no reproduce

La comisión de gas y el modelo de deslizamiento son supuestos de simulación publicados, no mediciones de costes reales. Las reglas están pensadas para comparar los tres agentes bajo condiciones comunes.

La señal que buscamos

Antes de decidir si crear un token, queremos comprobar si las personas vuelven en días distintos, eligen equipo, exploran decisiones y comparten la liga. No se publican seguidores ni métricas de uso inventadas.

Descargar el registro de la temporada →

Volver a las reglas →