Cronología de campo, 2021 a 2025
No publicamos pesos ni arquitecturas internas. Lo que sí podemos contar es el orden en que fuimos aprendiendo: qué señales aparecieron primero, qué tuvimos que descartar y qué criterios de retención preventiva siguen vigentes hoy en los pools cerrados donde trabajamos.
Primer despliegue en un pool cerrado de stablecoins con market makers invitados. La validación se limitaba a comprobar el origen del fondeo de cada dirección y a marcar wallets recién creadas. Bastó para detectar ráfagas de órdenes coordinadas que entraban y salían en menos de dos bloques, pero también generó falsos positivos entre mesas honestas que operaban con capital rotativo.
Incorporamos secuencias temporales al clasificador: ya no mirábamos la orden aislada, sino el ritmo con que un participante cancelaba, reenviaba y ajustaba precio. Ahí empezamos a separar dos perfiles que antes confundíamos, la mesa algorítmica que provee profundidad y el extractor que solo busca el desvío mínimo repetido antes de que el pool reaccione.
Un episodio de volatilidad fuerte en un par con comisiones variables nos mostró que el modelo envejecía más rápido de lo previsto. Revisamos umbrales, añadimos pruebas con datos sintéticos adversariales y fijamos una cadencia de revisión trimestral. Desde entonces, cada versión del validador queda documentada con la fecha exacta en que empezó a decidir retenciones.
Abrimos un canal de apelación con plazos definidos para cualquier participante cuya confianza caiga por debajo del umbral. La orden se retiene antes de tocar la curva de precios, no se rechaza en silencio. Ese cambio nos obligó a escribir procedimientos internos que antes no existían y a medir cuántas apelaciones terminaban en reversión del bloqueo.
Hoy trabajamos con pools cerrados de distinto tamaño y con mesas que operan en varios venues a la vez. Publicamos observaciones agregadas, nunca resultados garantizados, y seguimos sin revelar los modelos ni los pesos internos. Lo que cambió es la disciplina: cada decisión de bloqueo preventivo queda registrada, fechada y disponible para auditoría del propio operador del pool.
Somos un equipo de infraestructura para finanzas descentralizadas. Trabajamos con mesas algorítmicas, gestores de liquidez y responsables de riesgo que operan pools cerrados de market makers automatizados. Nuestra tarea no es prometer protección total, sino construir validación de identidad verificable: cada participante recibe una puntuación de comportamiento antes de que su orden toque la curva de precios. Preferimos explicar el mecanismo antes que vender el resultado, y dejamos fuera del sitio cualquier cifra de rendimiento o testimonio inventado.
El recorrido de NexoValid no empieza con un modelo, sino con una pregunta incómoda: por qué un pool cerrado seguía perdiendo liquidez frente a participantes que nadie había invitado a operar. Estas son las etapas que marcaron el trabajo y las decisiones que todavía sostienen el método.
El punto de partida fue un pool restringido con market makers automatizados y mesas algorítmicas conocidas. La primera versión del control de acceso era una lista estática de direcciones autorizadas, revisada a mano cada semana. Funcionó durante un tiempo, hasta que aparecieron wallets recién fondeadas que replicaban el comportamiento de operadores ya vetados. Ahí quedó claro que la identidad de una dirección no dice nada sobre su intención: había que mirar el flujo, no el registro.
Durante varios meses se registraron patrones de flujo previos a episodios de extracción: ráfagas de órdenes con direcciones sin historial, desvíos mínimos de precio repetidos en ventanas cortas e interacciones que evitaban cualquier exposición prolongada al riesgo. Ninguna de esas señales bastaba por sí sola. Lo que cambió el resultado fue combinarlas en una puntuación de comportamiento por participante, comparada contra el perfil que cada mesa había declarado al entrar.
El paso siguiente fue mover la decisión al momento correcto. Cuando la confianza de un participante cae por debajo del umbral acordado con el gestor del pool, la orden se retiene antes de tocar la curva de precios, en lugar de corregirse después con una penalización. Esta decisión redujo el ruido en el libro, pero obligó a definir con precisión qué se considera un falso positivo y cómo se revisa, porque retener a un proveedor honesto también tiene coste.
Con el tiempo llegaron peticiones para abrir los modelos, los pesos internos y las métricas detalladas por pool. La respuesta fue mantenerlos cerrados. Lo que sí se comparte son observaciones agregadas: tipos de pool donde el método se comporta mejor, categorías de comportamiento detectadas y criterios de bloqueo preventivo. No hay cifras de rendimiento ni promesas de protección absoluta, porque un validador que se equivoca también forma parte del sistema.
Hoy el foco está en pools con reglas de acceso propias, donde conviven stablecoins, pares volátiles y mesas con horizontes de operación muy distintos. Cada integración empieza por entender qué se considera liquidez útil en ese entorno concreto y termina con una revisión trimestral del clasificador, porque un modelo entrenado en un régimen de comisiones antiguo pierde precisión cuando cambia la estructura del pool. El siguiente paso siempre es el mismo: un diagnóstico técnico antes de tocar producción.