Pasé un tiempo mirando @NewtonProtocol today, y la parte que se quedó conmigo no fue el motor de políticas ni la verificación criptográfica. Fue el flujo de rechazo.
La autorización exitosa es casi invisible. Un agente de IA envía una transacción, se verifican las reglas, la acción se ejecuta y todos siguen adelante. Nadie se da cuenta realmente de la capa de confianza cuando funciona. Todo el sistema se vuelve visible solo cuando bloquea algo.
Ese “no” tiene que ser muy específico.
NewtonProtocol se construye en torno a la autorización programable para stablecoins, bóvedas DeFi, activos del mundo real tokenizados y agentes autónomos. La idea básica es práctica: antes de que el dinero se mueva, la transacción se comprueba frente a condiciones predefinidas. Los límites de gasto, los contratos aprobados, la elegibilidad de la billetera, las reglas de jurisdicción, la concentración de activos y otras restricciones pueden estar entre una instrucción y la liquidación.
Me gusta ese enfoque, pero la experiencia de usuario puede desmoronarse rápidamente si el mensaje de rechazo es ambiguo.
He tenido transacciones DeFi que fallan con errores que básicamente se traducen como “algo salió mal”. Mi reacción normal no es valorar el modelo de seguridad. Reintento la transacción, aumento el slippage, cambio los RPC o me paso a otra aplicación. Una vez pasé casi veinte minutos solucionando un swap antes de darme cuenta de que el monedero tenía una configuración de permisos antigua que bloqueaba la ruta. El control estaba haciendo su trabajo técnicamente, pero se sintió como un bug.
El mismo problema se vuelve más serio con agentes de IA.
Imagina dar permiso a un agente para administrar una posición de USDC. Intenta mover $8,000 a una bóveda de préstamos, pero el límite diario es de $5,000. Una capa de autorización útil debería decirle al agente exactamente eso. La cantidad excedió el tope diario por $3,000. El saldo de la autorización se restablece en seis horas. El contrato de destino está aprobado, pero el tamaño de la transacción no lo está.
“Falló la política” le dice al agente casi nada.
Sin una explicación clara, el agente podría reintentar la misma transacción, dividirla en transferencias más pequeñas, seleccionar un protocolo distinto o simplemente detenerse. Algunas de esas respuestas podrían, accidentalmente, eludir la intención original de la política. El sistema bloqueó la transacción, pero no necesariamente guió la siguiente acción de forma segura.
Eso es lo que creo que NewtonProtocol tiene que acertar. El comprobante de autorización puede ser válidamente criptográfico, pero la explicación tiene que ser comprensible tanto para humanos como para software.
Para stablecoins y RWAs, esto importa porque los activos a menudo parecen simples mientras que los permisos no. USDC puede mantener un precio estable, pero un activo estable aún puede enviarse a la dirección equivocada. Una posición tokenizada de Treasury puede parecer líquida, pero las transferencias pueden depender de verificaciones de identidad o elegibilidad. Un agente de IA puede ser competente encontrando rendimiento mientras aún malinterpreta quién tiene permiso para recibir el activo.
No creo que los usuarios vayan a juzgar a NewtonProtocol principalmente por lo avanzado que suene el sistema de verificación. Lo juzgarán la primera vez que una transacción se bloquee.
Si el mensaje dice exactamente qué pasó, qué regla se activó y qué acción aún está permitida, el rechazo se siente como una protección.
Si solo dice “autorización denegada”, se siente como la misma caja negra de siempre, pero con una criptografía mejor debajo.
