Anoche cambié el ángulo con el que lo miraba @NewtonProtocol . Antes, en cuanto escuchaba “agente de IA”, lo primero que me venía a la cabeza era: “autobuscando oportunidades, autocomprando y autogestionando para ahorrarme tiempo”. Pero cuanto más lo pienso en un escenario real, más claro me queda que lo más aterrador no es que la IA no sea suficientemente inteligente, sino que es demasiado diligente.

Hay una limitación natural en el trading humano: te da sueño, dudas, miras una vez más el monto. Incluso si a las dos de la mañana ves una oportunidad, con el dedo sobre el botón de confirmación, te detienes un momento y te preguntas si tocaste mal, si la posición es demasiado grande, si hoy ya has perdido demasiado. Un agente de IA no tiene ese problema. Si obtiene permisos sobre la billetera, puede ejecutar la estrategia de forma continua: cuando detecta la diferencia de precio, actúa; cuando ve una señal, entra; cuando se cumplen condiciones, transfiere; cuando encuentra un protocolo, lo llama. La rapidez es una ventaja, pero la velocidad sin límites también es un riesgo.

Así que cuando miro @NewtonProtocol Newton Protocol, lo que más me conmueve no son solo esas palabras “trading automático con IA”, sino la capa de authorization que explica el whitepaper: es decir, la capa de autorización entre la intención de la transacción y la ejecución on-chain. En palabras simples, no está creando otra billetera ni diciendo “usa IA para que sea más inteligente”; antes de que la IA mueva el dinero de verdad, primero hace unas preguntas muy sencillas:

¿Se puede gastar este dinero?

¿A quién se le paga?

¿Cuánto se ha gastado hoy?

¿Entró en los protocolos permitidos?

¿Te has encontrado con direcciones de riesgo?

Cuando el monto es grande, ¿hay que actualizar la aprobación?

Estos problemas suenan poco llamativos, pero precisamente creo que son las cosas que un agente de IA en cadena debe resolver primero. Porque la ejecución on-chain es demasiado directa: una vez que se transmite el broadcast de la firma, no es como en un panel tradicional de backend donde aún se puede retirar lentamente. Muchos accidentes no ocurren porque la gente no sepa el riesgo, sino porque las reglas del riesgo no se ciñen de verdad antes de la ejecución.

Ahora muchos proyectos ponen el control de riesgos en páginas del frontend o en monitoreo posterior. Las alertas del frontend, por supuesto, ayudan, pero no impiden que llames directamente al contrato; el monitoreo posterior también sirve, pero cuando el dinero ya salió, cualquier alarma bonita parece un informe de accidentes. La idea de Newton es convertir las reglas en policy para que la transacción pase primero esa “aduana” antes de ejecutarse. Si pasa, el contrato inteligente obtiene una prueba verificable y sigue; si no pasa, no dejes que ocurra.#Newt

Me gusta muchísimo entenderlo como el “sistema de frenos del agente de IA”. Incluso si un coche tiene mucha potencia, si no tiene frenos, nadie se atreve a subirse y confiar. El agente de IA es igual. Puede ayudarme a ejecutar estrategias, pero quiero que primero le trace límites: por transacción, no más de 800 USDT; acumulado en 24 horas, no más de 3000 USDT; solo se permite interactuar con algunos protocolos en lista blanca; si hay movimientos anómalos de precio, se pausa; direcciones de alto riesgo se rechazan directamente; y si se exceden los límites, se requiere confirmación manual.

Aquí se puede poner un ejemplo muy común. Supongamos que le doy a un agente 5000 USDT para que mueva fondos entre tres pools de rendimientos estables. Antes solo podía confiar en el código de su estrategia y, como mucho, establecer un límite de un monedero. Pero el riesgo real no es solo “¿pierde o no pierde?”. También hay muchas situaciones grises: ¿entrará en un protocolo que no he visto, solo por ganar 0,3% de APY extra? ¿Seguirá ejecutando cuando la liquidez de repente se vuelva más delgada? ¿Llamará igual si el frontend o la dirección del contrato fueran falsas? ¿Haría, en un solo día, operaciones seguidas durante una docena de veces para ir puliendo comisiones y deslizamientos?

Si estos problemas los resuelvo solo mirando los registros después, ya es tarde. Una forma más razonable es escribirlo como policy antes de ejecutar: la lista blanca de protocolos es solo A, B y C; el monto de una sola migración no supera el 20% del principal; como máximo se ejecuta 3 veces en 24 horas; si el TVL del pool objetivo está por debajo de cierto umbral, se rechaza; si la tasa de rendimiento sube de forma anormal, se pausa, porque quizá sea una compensación por riesgo y no un “almuerzo gratis”. Así, el agente no es que no pueda trabajar, sino que solo puede trabajar dentro de los límites que yo puedo aceptar.

Estas reglas, si solo se escriben en un chat, no sirven de nada. Lo verdaderamente valioso es que la máquina pueda entenderlas, que el operador pueda evaluarlas, que el contrato inteligente pueda comprobarlas y que luego también quede un registro. En el whitepaper de Newton se menciona Rego / OPA; mi interpretación es que “no gastes al azar, no entres en protocolos al azar, no hagas operaciones fuera de los permisos” se convierta en reglas ejecutables por máquinas. No es como un acuerdo verbal humano que hoy se recuerda y mañana se olvida; es más bien un reglamento de trabajo en cadena.

Hay otro punto muy de tierra: los recibos de cumplimiento. En cada evaluación de policy se puede dejar un registro, ligado a la intención de la transacción, las reglas, la respuesta del operador, la firma agregada y la información de la blockchain. Esto quizá al principio no parezca importante para un usuario normal, pero cuando de verdad pasa algo, es crucial. No solo quiero que me digan “la evaluación del sistema pasó”; quiero saber por qué pasó. No solo quiero que me digan “la transacción fue rechazada”; quiero saber en qué regla se atascó.

Creo que “saber dónde se atascó” es muy importante. Muchas veces el fracaso de un producto no se debe a que no haya reglas, sino a que los usuarios no saben cómo esas reglas se aplican. Por ejemplo, si se rechaza una transacción, lo que ve la gente común es solo el fallo. Pero si se pudiera ver el motivo: “se alcanzó el límite diario”, “el protocolo objetivo no está en la lista blanca”, “los datos de precio no llegaron a un consenso”, “se requiere confirmación manual”, entonces los usuarios no interpretarían todos los fallos como que el sistema está mal. Al mismo tiempo, el equipo del proyecto tampoco tendría que depender cada vez de explicaciones del servicio al cliente; el recibo de autorización on-chain en sí es la evidencia.

Esta también es la parte donde creo que $NEWT tiene diferenciación. No se limita a hablar de conceptos de IA; aborda el problema de permisos que es más fácil de ignorar en los agentes de IA. En el futuro, si cada persona puede crear sus propias estrategias de automatización, el problema no será si “el robot sabe operar”, sino si “el robot tiene derecho a operar, hasta qué nivel puede operar y si se puede rastrear cuando se equivoca”.

No quiero entregar la billetera a un agente que solo sabe decir “confía en mí”. Aunque tenga una tasa de aciertos muy alta, no me sentiría tranquilo. Prefiero entregar los permisos a un sistema que pueda ejecutar reglas, dejar recibos, ser cuestionado y permitir una revisión posterior. La IA puede ir rápido, pero el dinero no puede ir con los ojos vendados.

Por eso ahora miro Newton Protocol y ya no lo clasifico simplemente como un proyecto de trading con IA. Más bien se parece a haberle puesto un semáforo de rojo y verde a la automatización on-chain: con luz verde se avanza, con luz roja se detiene y con luz amarilla se pasa a un manejo de actualización. A corto plazo quizá no tenga el mismo “enganche” que los anuncios de señales, pero si de verdad los agentes de IA van a entrar en DeFi, pagos con stablecoins, RWA o gestión de activos institucionales, esta capa de infraestructura de autorización será cada vez más importante.

Dicho de forma más realista, en el futuro la mayoría de usuarios no leerán los contratos por su cuenta, ni van a estar mirando operador, firmas y detalles de bajo nivel como pruebas cada día. Los usuarios solo preguntarán tres cosas: ¿la autorización que doy tiene algún límite? ¿cuando el sistema rechaza una operación hay una razón? ¿después de que algo sale mal hay forma de rastrear por qué? Si Newton logra hacer bien estas tres, recién entonces hay una oportunidad de que la gente común se sienta confiada usando la automatización on-chain. Si no, aunque el agente de IA sea inteligente, será difícil convertirlo de “herramienta para probar” en una “estrategia de custodia a largo plazo”.

Esta también es la razón por la que seguiré prestándole atención. Hay muchos proyectos de IA capaces de contar historias, pero no son tantos los que logran explicar con claridad ese tipo de trabajo sucio y pesado: los “límites de permisos”. Cuando de verdad se aterriza, a los usuarios muchas veces no les hace falta un eslogan más grande, sino que puedan dormir tranquilos: si la estrategia seguirá corriendo o no por la noche.

Mi criterio para $NEWT también es simple: el verdadero AI on-chain no consiste en darle libertad infinita a un robot, sino en permitirle ser libre dentro de límites claros. Cuanto más claros sean los límites, más valiente será la automatización para usarse.