El año pasado hice una cosa que ahora, viéndolo, parece extremadamente imprudente: entregué los permisos de derivación de un monedero en frío a un agente de trading (open source), para que hiciera arbitraje moviendo fondos automáticamente entre tres DEX. Las dos primeras semanas salieron casi perfectas; el Sharpe era tan alto que por un momento pensé que ya podía retirarme. Hasta que una madrugada, un pool de stablecoins se desancoró de repente. El agente, siguiendo parámetros antiguos, se puso a recomprar y reponer con locura; el deslizamiento y las comisiones se fueron sumando, y en una hora se comió cerca de un 40% de mi liquidez. En todo el proceso no hubo ni un solo paso que superara los permisos que yo le había dado entonces; simplemente cambiaron las condiciones y el agente no tenía la obligación de detenerse para preguntarme.

Esto me hizo darme cuenta de que el mayor engaño de la automatización on-chain es disfrazar el “ejecutar rápido” como “ejecutar bien”. Cuando autorizamos a un agente, en realidad no entregamos una llave privada, sino una confianza incondicional en todo el proceso de ejecución. Pero el mundo on-chain cambia todo el tiempo: los desvíos del oráculo, migraciones de pool, retrasos del puente, el empuje de nonces… Cualquier variable que se vuelva obsoleta, y ese supuesto agente “inteligente” se convierte en una trituradora de carne a máxima potencia.

Por eso es que empiezo a mirar en serio @NewtonProtocol . No me está enseñando cómo hacer estrategias, sino cómo restringir lo que el ejecutor puede hacer. Concretamente, primero el usuario define un conjunto de límites de estrategia: una lista blanca de contratos invocables, el monto máximo por operación, los rangos de deslizamiento permitidos, y la condición de activación junto con la máxima diferencia de tiempo entre el disparo y la ejecución. Antes de que el agente envíe una transacción, debe ejecutar simulatePolicy: como una lista de verificación previa al despegue para un piloto. Si no se cumple cualquiera de los requisitos, la validación de la estrategia rechaza la firma.

Esto es mucho más fino que el modelo de permisos que usaba antes, de “o no te doy la llave, o te doy el coche entero”. Antes estábamos acostumbrados a autorizaciones a nivel de app: una confirmación y ya tenías llamadas ilimitadas a todo el contrato. Newton descompone esa lógica en granularidad mucho más detallada: tu agente puede vender A, pero no puede mover B; puede operar dentro de una tolerancia de deslizamiento del 0,5% y, si la supera, se detiene inmediatamente; puede repagar deuda, pero no puede retirar el dinero a una dirección desconocida. En otras palabras, el agente de IA queda encerrado en una especie de jaula diseñada, y esa jaula es precisamente lo que lo protege para que no cause problemas.

Además, me fijé en que también mencionan la generación de pruebas ZK y la TEE. Juntas, en realidad están respondiendo a una pregunta más profunda: ¿por qué debería creer que el agente tomó las decisiones según mis reglas? Con ZK, el resultado de validar la estrategia se comprime en una prueba; solo le dice a los demás que “esta llamada cumple las restricciones predefinidas”, sin necesidad de revelar los detalles de la estrategia ni el estado de las cuentas. La TEE, por su parte, proporciona un entorno de aislamiento a nivel de hardware para cálculos sensibles y la firma, evitando que claves y parámetros de la estrategia sean observados en un servidor normal. Así, incluso si el entorno de ejecución no es confiable, el resultado de la ejecución sigue siendo verificable.

Alguien podría decir que esto reduce la eficiencia del agente: hay que verificarlo todo cada vez, ¿y si se vuelve lento? Pero no creo que sea una desventaja. La gestión de activos on-chain y el trading de alta frecuencia de cripto son lógicas completamente distintas: cosas como el control de posiciones, evitar liquidaciones y el rebalanceo de la cartera, en realidad no requieren una respuesta a nivel de milisegundos. Lo que necesitan es que cada paso esté dentro de un margen de seguridad, para que un retraso en un estado asíncrono no arrastre toda la posición. Cuando de verdad importa ir rápido, como en los “robos” (race) en la línea de liquidación, entonces también se necesita depender de reglas de emergencia definidas con antelación, en lugar de que la IA improvisa sobre la marcha.#Newt

Si comparamos un agente on-chain con un coche de conducción autónoma, lo que ahora hace Newton Protocol es más bien como instalar primero un limitador de velocidad, los frenos y el registrador de conducción. Primero poder detenerse de forma segura, y recién luego hablar de correr rápido. Todavía estoy observando la frecuencia con la que actualizan sus estrategias y los mecanismos de rollback ante anomalías, especialmente si estas verificaciones pueden fallar en el caso de estados entre cadenas debido a retrasos del relé. Pero la dirección ya está bastante clara: si también quieres dejar tu posición a largo plazo en manos de un programa, no te apresures a entrenar su curva de ganancias; primero piensa si tiene o no una jaula.

#newtrend $NEWT @NewtonProtocol