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 indexábamos cada transacción en Osmosis, hasta dos millones al día. Los datos los teníamos. Lo que nos faltaba era una forma de separar el trading genuino del wash trading, la manipulación de ballenas y la actividad coordinada de bots. Monté 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 encontraba 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 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 si en Numia 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 indexábamos 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.

En detección de anomalías de trading no existe la verdad absoluta. No puedes etiquetar transacciones históricas como "anómalas" o "normales" porque eso es precisamente lo que intentas averiguar. El aprendizaje supervisado quedó descartado desde el día uno. 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 simple: 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, así que nada se marca como anómalo. Demasiado pocas y no aprende los patrones normales lo suficiente como para notar 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 dicen poco. Las features que de verdad importaron: patrones de gas (bots y operaciones urgentes muestran un comportamiento distintivo; una wallet que de repente paga 10x 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).

Un Silhouette Score de 0,909 indicaba 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 siempre, pero con la frecuencia suficiente para que los equipos de protocolo pudieran actuar.

La arquitectura

Monté la pipeline completa en GCP, sobre la infraestructura existente de Numia, así que funcionó en producción desde el primer día.

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

El comportamiento del mercado deriva 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 un ID único y métricas de evaluación rastreadas para cada uno. Los modelos nuevos se despliegan vía blue-green sin downtime, y si la versión nueva 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, dispara el reentrenamiento de forma automática.

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 varias ocasiones. No es una bola de cristal, pero lo bastante consistente para que los equipos de protocolo actuasen.
• Escala: 2M+ transacciones diarias analizadas con latencia de alertas sub-segundo, corriendo sobre nuestra infraestructura existente en GCP.
• Portabilidad: La metodología se traslada a cualquier DEX con datos a nivel de transacción. Lo diseñamos sobre 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 sí pueden encontrar estructura real en datos blockchain sin etiquetar. El Silhouette score de 0,909 fue una buena validación, pero lo que me convenció de verdad fue ver al sistema marcar acumulación de ballenas antes de movimientos de precio en tiempo real. O detectar trading coordinado entre docenas de wallets que sobre el papel parecían completamente inconexas.

Pasado cierto umbral de precisión, la latencia importa más que afinar el modelo. 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 confirmarse un bloque vale infinitamente más que una señal perfecta dos minutos tarde. La pipeline sub-segundo resultó ser la decisión de ingeniería más importante de todo el proyecto.

Montarlo sobre nuestra propia infraestructura de producción significó que fue útil desde el primer día. Validarlo estadísticamente de forma rigurosa lo hizo fiable. He aplicado esa misma combinación a cada proyecto desde entonces.