Los pequeños inversores usan sus propias carteras y, muchas veces, aún pueden corregir las cosas con experiencia. Si el contrato no es el adecuado, puedes detenerte; si detectas una autorización anómala, puedes ir a revocar; y si pierdes, como mucho, la pérdida es la de tu propia cuenta. Pero si se trata de fondos de instituciones, tesorerías de DAO, DeFi Vault o pagos con stablecoins a nivel empresarial, una ejecución errónea puede afectar no solo a una persona, sino a todo un conjunto de fondos, a los derechos de los usuarios y a una cadena de responsabilidades.
Así que creo que @NewtonProtocol es una de las partes que vale la pena ver: no porque simplemente se limite a aprovechar la narrativa de los agentes de IA, sino porque plantea un problema más realista. A medida que las operaciones on-chain se automatizan cada vez más, ¿quién decide si esta operación “puede ejecutarse” o no?
Muchos protocolos en el pasado resolvían problemas después de la transacción. Si la transacción tuvo éxito, si los fondos llegaron, si el contrato se ejecutó según el código: todo eso puede verificarse on-chain. Pero el verdadero peligro suele ocurrir antes de la transacción: ¿este agente tiene permisos? ¿Esta llamada supera el límite de cuota? ¿Este contrato está en una lista blanca? ¿Se puede transferir este activo a esa dirección? ¿La estrategia ya se desvió del rango de autorización original?
Si estas comprobaciones dependen de avisos en el front-end, de revisiones manuales o de registros en el panel del equipo del proyecto, entonces cuanto mayor sea la automatización, mayor será el riesgo. Porque un agente no duda como lo haría una persona: simplemente ejecuta las instrucciones. Si la instrucción está mal, si el entorno cambia o si los permisos se usan de forma indebida, la liquidación on-chain seguirá siendo muy “honesta” al ejecutar el error hasta el final.
Lo que Newton quiere añadir es esa capa de “verificación antes de ejecutar”. Abstracta permisos, identidad, límites de cuotas, condiciones de riesgo y los límites de la estrategia en una Policy, de modo que la transacción no entre directamente en el contrato: primero pasa por una validación de reglas. Esta lógica es muy parecida a poner una barrera de control de riesgos on-chain a un agente de IA: no se trata de limitar la automatización, sino de hacer que la automatización opere dentro de un rango controlable.
Esto es especialmente importante para un Vault. Una estrategia de automatización puede ajustar la cartera, reequilibrar y llamar a través de protocolos, pero lo que el usuario realmente le preocupa es: ¿moverá el dinero de forma desordenada? ¿Tocará protocolos de alto riesgo? ¿Superará el límite por operación? ¿Seguirá ejecutándose en un escenario de mercado anómalo? Si estos límites pueden escribirse con antelación en Policy, la confianza del usuario ya no proviene solo de las promesas del equipo, sino de la propia ruta de ejecución.
Por supuesto, esta ruta tampoco es fácil. La capa de reglas es demasiado débil y no protege los fondos; si es demasiado pesada, también puede ralentizar la eficiencia de ejecución. Si la configuración de Policy es demasiado compleja, los desarrolladores comunes no querrán usarla; si es demasiado simple, será difícil cubrir escenarios reales de instituciones. Lo que Newton debe demostrar después no es que el concepto sea más completo, sino si puede encontrar un equilibrio entre costo, latencia, seguridad y disponibilidad.
Por eso veo a $NEWT: no solo miraría el entusiasmo por los agentes de IA, ni solo la actividad de corto plazo. Me interesa si puede permitir que más operaciones automatizadas on-chain tengan límites de ejecución claros. Porque si Web3 realmente entra en la era de agentes, el problema más importante no será “quién corre más rápido”, sino “quién puede correr rápido sin hacer que los fondos se vayan volando”.
¿Crees que Newton es la base de control de riesgos para la era de los agentes de IA, o que aún es demasiado adelantada la infraestructura para esta etapa?