DEX Anomaly Detection

Los protocolos nos hacían siempre la misma pregunta: ¿cómo sabemos si el trading en nuestro DEX es real? En Numia ya estábamos indexando cada transacción en Osmosis, hasta dos millones al día. Teníamos los datos. Lo que no teníamos era una forma de separar el trading genuino del wash trading, la manipulación de ballenas y la actividad coordinada de bots. Construí un pipeline de ML no supervisado para responder esa pregunta. Sin etiquetas, sin ground truth, solo datos brutos de transacciones alimentando un ensemble de autoencoders que aprendió cómo es lo "normal" y marcó todo lo que no lo era. El sistema detectó patrones de acumulación de ballenas antes de subidas de precio, y un Silhouette score de 0,909 confirmó que el modelo estaba encontrando estructura real en los datos.

El problema

El trading en DEX es opaco por diseño. Cualquiera puede crear wallets y operar contra sí mismo para inflar las cifras de volumen. Los protocolos que toman decisiones de governance basándose en métricas de trading, los proyectos de tokens evaluando dónde listar, todos necesitan confiar en que los números son reales. Y para nosotros en Numia, si somos la capa de datos de la que dependen estos clientes, teníamos que poder responder esa pregunta nosotros mismos.

Osmosis fue el punto de partida natural. Ya estábamos indexando todo el ecosistema Cosmos, y Osmosis tenía el mayor volumen. Más de dos millones de transacciones diarias en pico, datos inusualmente limpios gracias a la arquitectura del Cosmos SDK, y requisitos de latencia sub-segundo porque las alertas que llegan después del movimiento no sirven de nada.

No existe ground truth en la detección de anomalías de trading. No puedes etiquetar transacciones históricas como "anómalas" o "normales" porque eso es exactamente lo que estás intentando averiguar. El aprendizaje supervisado quedó descartado desde el primer día. La pregunta era: ¿pueden los modelos no supervisados separar patrones significativos del ruido, y si lo hacen, se correlacionan esos patrones con eventos reales de mercado?

El producto

Probé cinco enfoques: autoencoder denso, One-Class SVM, Isolation Forest, K-Means y baselines estadísticos. El autoencoder ganó de forma decisiva, pero mantuve el ensemble porque cada modelo captura distintos tipos de patrones.

La idea del autoencoder es sencilla: entrenar una red neuronal para comprimir y reconstruir transacciones normales. Cuando pasa algo inusual, el error de reconstrucción se dispara. Pasé semanas ajustando la arquitectura. Demasiadas capas y lo memoriza todo, con lo que nada se marca como anómalo. Demasiado pocas y no aprende los patrones normales lo suficiente como para notar las desviaciones. El punto óptimo resultó ser un encoder de 5 capas con dropout, y el Silhouette score de 0,909 demostró que funcionaba con datos reales.

One-Class SVM e Isolation Forest capturan lo que el autoencoder no detecta. OCSVM traza un límite alrededor de lo "normal" en el espacio de features. Isolation Forest encuentra puntos de datos inusualmente fáciles de separar del resto. Matemáticas diferentes, resultados complementarios. Fijé el ratio de outliers en un 5% en todos los experimentos. Arbitrario, sí, pero la comparación consistente importaba más que exprimir un porcentaje extra de cada modelo por separado.

Los datos brutos de transacciones por sí solos no dicen gran cosa. Las features que realmente importaron: patrones de gas (los bots y operaciones urgentes muestran un comportamiento distintivo, una wallet que de repente paga 10 veces su gas habitual merece atención), clustering de wallets (una wallet es ruido, veinte wallets haciendo lo mismo al mismo tiempo es señal), actividad cross-chain (las transferencias IBC hacia Osmosis a menudo llegan justo antes de grandes operaciones), y patrones temporales (el retail opera en horario de mercado estadounidense, la actividad institucional aparece a horas extrañas).

El Silhouette Score de 0,909 significaba que el modelo encontró un límite real en los datos, no simple ruido aleatorio. Los tests Mann-Whitney U compararon las anomalías detectadas con las transacciones normales en volatilidad, volumen e impacto en precio, con diferencias estadísticamente significativas en todas las métricas. Los patrones de acumulación de ballenas detectados precedían subidas de precio. No todas y cada una de las veces, pero con la frecuencia suficiente para que los equipos de protocolo pudieran actuar en consecuencia.

La arquitectura

Construí el pipeline completo en GCP, sobre nuestra infraestructura existente de Numia, así que funcionó en producción desde el principio.

Latencia sub-segundo desde la confirmación en blockchain hasta la entrega de la alerta. Pub/Sub ingesta transacciones desde nodos blockchain con entrega at-least-once, lo que significaba que el feature engineering tenía que ser idempotente. Cloud Functions maneja la predicción stateless (los cold starts fueron un auténtico quebradero de cabeza hasta que añadí concurrencia aprovisionada para las rutas críticas). Firestore alimenta las alertas en tiempo real al dashboard de monitorización. BigQuery maneja el almacenamiento histórico para entrenamiento, conectándose al data warehouse que ya teníamos en marcha. El modelo se reentrena semanalmente con los datos más recientes.

El comportamiento del mercado cambia con el tiempo. Un modelo entrenado con datos de enero empieza a quedarse obsoleto en marzo. Vertex AI gestiona ejecuciones de entrenamiento y versiones de modelos, con cada modelo recibiendo un ID único y métricas de evaluación rastreadas a lo largo del tiempo. Los nuevos modelos se despliegan vía blue-green sin tiempo de inactividad, y si la nueva versión rinde peor, el rollback automático entra en acción. La monitorización de drift rastrea distribuciones de features y confianza de predicción. Cuando el modelo empieza a perder certeza, lanza el reentrenamiento automáticamente.

Resultados

El sistema funcionó en producción y los números aguantaron el escrutinio.

• Precisión del modelo: Silhouette score de 0,909 en el autoencoder, con tests Mann-Whitney confirmando que las anomalías eran estadísticamente distintas de las transacciones normales en volatilidad, volumen e impacto en precio.
• Valor predictivo: El sistema marcó acumulación de ballenas el día antes de un movimiento de precio del 15% en múltiples ocasiones. No una bola de cristal, pero lo suficientemente consistente para que los equipos de protocolo actuasen.
• Escala: 2M+ transacciones diarias analizadas con latencia de alertas sub-segundo, corriendo sobre nuestra infraestructura existente de GCP.
• Portabilidad: La metodología se transfiere a cualquier DEX con datos a nivel de transacción. Lo diseñamos en Osmosis, pero el enfoque central funciona en Uniswap, Curve o PancakeSwap. El feature engineering cambia según la cadena, la lógica de detección no.

Lo que aprendí

Los modelos no supervisados pueden encontrar estructura real en datos blockchain sin etiquetar. El Silhouette score de 0,909 fue una buena validación, pero lo que realmente me convenció fue ver cómo el sistema marcaba acumulación de ballenas antes de movimientos de precio en tiempo real. O ver cómo emergía trading coordinado entre docenas de wallets que sobre el papel parecían completamente inconexas.

A partir de cierto umbral de precisión, la latencia importa más. Podríamos haber conseguido una detección ligeramente mejor ejecutando modelos más pesados, pero una señal que llega dos segundos después de que se confirme un bloque es infinitamente mejor que una señal perfecta dos minutos tarde. El pipeline sub-segundo resultó ser la decisión de ingeniería más importante de todo el proyecto.

Construirlo sobre nuestra propia infraestructura de producción significó que fue útil desde el primer día. Pasar por una validación estadística rigurosa lo hizo fiable. He aplicado esa misma combinación a cada proyecto desde entonces.