Cómo los agentes de IA operan en blockchain: intenciones y…

Cómo los agentes de IA ejecutan operaciones en la cadena se reduce a la plomería, no a la “magia de la IA”: el agente produce intenciones firmadas que otros actores convierten en cambios de estado de Ethereum. La operación solo se liquida si dos rieles están conectados correctamente, el riel de ejecución (transacción EOA o UserOperation ERC-4337) y el riel de permisos de token (asignaciones o permisos al estilo Permit2).

Puntos clave

• Un agente de IA no “opera” por sí mismo en Ethereum. Debe controlar o estar autorizado por una cuenta en la cadena que pueda activar llamadas a contratos y transferencias de tokens.
• Hay dos rieles de ejecución: una transacción originada en EOA, o una UserOperation ERC-4337 que un agrupador envía al contrato EntryPoint para verificación y ejecución.
• Los intercambios requieren permiso explícito de gasto de tokens antes del movimiento de tokens, y Permit2AllowanceTransfer agrega expiraciones y nonces por (propietario, token, gastador) para proteger y evitar la repetición de ese permiso.
• Para un tamaño mayor o controles más estrictos, un Safe puede separar funciones permitiendo que el agente proponga una transacción mientras múltiples propietarios confirman antes de la ejecución.

Cómo un agente de IA puede operar en la cadena

La salida de un modelo no es una acción en la cadena. La cadena solo reacciona a mensajes que pasan las verificaciones de firma y llaman a contratos desde una cuenta que posee activos.Esa es la realidad fundamental detrás del comercio autónomo en la cadena: el “agente” es un motor de decisión fuera de la cadena, y la parte en la cadena es una cuenta más una solicitud firmada que la red aceptará.

Dos rieles aparecen en un explorador de bloques. El primero es el riel de ejecución, lo que significa cómo la solicitud se convierte en una transacción de Ethereum. En Ethereum, solo una Cuenta Externamente Propietaria puede originar una transacción, porque un EOA está controlado por una clave privaday firma la transacción directamente.

Un contrato inteligenteuna cuenta puede mantener activos y ejecutar lógica, pero no puede originar una transacción por sí sola. Solo realiza trabajo cuando es llamada por algo más.

El segundo riel es el movimiento de tokens. UnDEXel intercambio no es “solo llamar a un enrutador.”ERC-20los tokens no se mueven porque se llamó a una función de intercambio. Se mueven porque el propietario del token ha otorgado autoridad de gasto a algún gastador, y luego ese gastador utiliza esa autoridad para transferir tokens.

Si el agente está construyendo la ejecución de agentes en la cadena que toca los ERC-20, tiene que resolver ambas vías cada vez: (1) hacer que la cadena ejecute llamadas, y (2) asegurarse de que el contrato correcto esté autorizado para retirar la cantidad correcta de tokens.

Aquí es donde se agrupan los productos de DeFi: ejecución autónoma envuelta en la experiencia de usuario de la billetera, con límites en lo que se firma y lo que se gasta. El modelo mental útil es el mismo que está detrás de lo que es la ejecución autónoma en cadena de DeFi como categoría: el agente autoriza intenciones, y la infraestructura convierte esas intenciones en liquidación.

El pipeline de ejecución ERC-4337

ERC-4337 convierte "enviar una transacción" en una cadena de suministro con actores adicionales, lo que cambia las suposiciones de fiabilidad. En lugar de que un EOA transmita una transacción al mempool público, una billetera ERC-4337 construye un objeto UserOperation y se lo entrega a un bundler que más tarde envía una transacción onchain a un contrato EntryPoint singleton.

El flujo de extremo a extremo es más fácil de rastrear como una secuencia:

1. El agente prepara una carga útil. Para una billetera de agente que es una cuenta inteligente ERC-4337, la carga útil es una UserOperation con campos como remitente, nonce, callData, límites de gas, parámetros de tarifa y una firma.2. El agente envía la UserOperation a un mempool alternativo. Las billeteras normalmente lo envían a un punto final RPC de agrupador en lugar de al pool de transacciones estándar de Ethereum.3.

Un agrupador recopila y simula. Los agrupadores observan el alt-mempool, simulan UserOperations candidatas y deciden cuáles incluir en un paquete.

4. El agrupador origina la transacción en cadena. El agrupador llama a EntryPoint.handleOps con un array de UserOperations, y esa llamada es la transacción real de Ethereum que se registra en un bloque.5. EntryPoint verifica y luego ejecuta. EntryPoint sigue un patrón de dos fases: llama a validateUserOp en la cuenta (y validatePaymasterUserOp si hay un paymaster adjunto) y solo entonces ejecuta la fase de ejecución.6.

El gas se liquida a través de prefondos o un paymaster. ERC-4337 permite que un contrato Paymaster patrocine el gas reembolsando al agrupador bajo reglas definidas.

Para la mecánica del agente de trading de IA, el punto clave no es el formato de la firma. Es quién es responsable de la inclusión. Con ERC-4337, 'ejecutado por el agente' no es cuando el agente firma. Es cuando EntryPoint ejecuta, y eso depende del comportamiento del agrupador y las reglas del paymaster si el gas es patrocinado.

Cómo los agentes obtienen permiso para gastar tokens.

El movimiento de tokens es donde la mayoría de los diseños de agentes filtran riesgo, porque los permisos tienden a sobrevivir al comercio. El modelo limpio es permiso primero, ejecución segundo. ERC-4337 puede comprimir esos en un solo acuerdo al agrupar múltiples acciones en una sola UserOperation, pero la autorización aún debe ser explícita y limitada.El AllowanceTransfer de Permit2 de Uniswap es un conjunto concreto de primitivas para esta capa. Soporta tres puntos de entrada principales: aprobar (establecer permisos en cadena), permitir (establecer permisos a través de una firma) y transferFrom (gastar cuando ya existen permisos válidos). La diferencia importante frente al viejo hábito de 'aprobar máximo para siempre' es que las asignaciones de Permit2 pueden estar limitadas en el tiempo utilizando una marca de tiempo de expiración.

Permit2 también ofrece un manejo práctico de protección contra repetición que los agentes pueden utilizar. Su esquema de nonce incrementa los nonces por propietario, por token y por gastador, empaquetados en un mapeo de asignaciones. Eso significa que un permiso no es solo '¿firmó el propietario una vez?', sino '¿firmó el propietario esta ventana de gasto específica para este gastador, y ya se ha consumido ese nonce?'.

El permiso de Permit2 admite firmas EOA, firmas compactas EIP-2098 y firmas de contrato EIP-1271, lo cual es importante cuando el propietario es una cuenta inteligente en lugar de una EOA.

Para cómo los agentes comercian en DeFi, este es el patrón operativo que aparece cuando las cosas se construyen cuidadosamente:

1. El agente solicita una ventana de gasto estrecha. La cantidad está limitada, la expiración es corta, el gastador es específico. 2. El agente empaqueta la autorización con la ejecución. Un permiso o aprobación puede combinarse con la llamada de intercambio para que la asignación no quede sin usar. 3. El agente gasta a través de transferFrom solo dentro de esa ventana. Si la ventana expira, el permiso está muerto en la cadena.

Aquí es también donde encajan conceptualmente la ejecución basada en intenciones y una red de solucionadores. El agente puede firmar una intención que expresa el resultado deseado, mientras los solucionadores compiten para enrutarlo y liquidarlo. Independientemente de quién enrute, el riel de permisos de tokens aún decide qué se puede extraer de la cuenta del propietario.

Controles multisig y de políticas con Safe

El patrón de control más robusto para dinero real es la separación de políticas: permitir que el agente proponga, pero requerir un umbral de Safe para ejecutar. Eso mantiene la automatización mientras elimina la autoridad unilateral de una sola clave de ejecución.

El flujo documentado de Safe es explícito sobre las transferencias. Se crea una transacción, se propone al Servicio de Transacciones de Safe, se confirma por otros propietarios y solo entonces se ejecuta.

En la guía del Kit de Protocolo de Safe, la secuencia es: crear un objeto de transacción, calcular el hash de la transacción de Safe, proponerlo para que otros propietarios puedan verlo, recopilar confirmaciones (firmas) de los propietarios, y luego ejecutar con executeTransaction.

Eso es importante para la ejecución autónoma porque cambia lo que significa 'acción del agente'. El agente puede generar el calldata exacto para una llamada de enrutador DEX, o para un executeBatch de una cuenta ERC-4337, pero el Safe es el escritorio de riesgos que decide si esa carga útil puede llegar a la cadena.

Este es un lugar limpio para hacer cumplir políticas que las fuentes no estandarizan para los agentes, como limitar nuevos gastadores, requerir confirmaciones adicionales para nuevos tokens o restringir el tamaño.

Safe también se adapta bien a los patrones de clave de sesión en la capa de cuenta. Las cuentas ERC-4337 pueden validar diferentes esquemas de firma dentro de validateUserOp, y una clave de sesión puede ser uno de esos esquemas. El punto no es la palabra de moda. El punto es que una clave de corta duración puede ser autorizada para acciones limitadas mientras que los propietarios a largo plazo retienen el control último.

Para los equipos que construyen sistemas de defai, esta es la diferencia entre 'el agente puede comerciar' y 'el agente puede redactar operaciones comerciales'. Redactar es barato. La ejecución es donde ocurren cambios de estado irreversibles.

Compromisos de diseño y modos de fallo

El primer modo de fallo es la confusión de tipos de mensajes. Un UserOperation no es una transacción de Ethereum. Es datos en un mempool alternativo hasta que un bundler lo envuelve en una llamada a EntryPoint.handleOps. Por eso las cuentas de contratos inteligentes no pueden "simplemente enviar transacciones como los EOAs". Solo los EOAs originan transacciones, y las cuentas inteligentes actúan cuando son llamadas.

El segundo modo de fallo es tratar al bundler como una infraestructura invisible. ERC-4337 cambia las suposiciones de "mi billetera transmite" a "¿me incluirá un bundler?" La descripción de Eco es explícita en que los bundlers observan el alt-mempool, simulan y envían paquetes, pagando gas de L1 y siendo reembolsados de prefonds o pagadores.

Si un endpoint de bundler está caído, limitado en tasa o rechazando ciertas operaciones, el agente puede seguir firmando y nada se liquidará.

El tercer modo de fallo es la expansión de permisos. Las aprobaciones ilimitadas no son una característica de comercio. Son una superficie de pérdida constante. Las marcas de tiempo de expiración de Permit2 y los nonces por (propietario, token, gastador) son los controles onchain que pueden limitar esa superficie, pero solo si la integración los utiliza.

Un error común de integración es autorizar al gastador equivocado o pasar el de address en una llamada de transferencia, lo que Uniswap señala como una consideración de seguridad para integrar contratos.

El cuarto modo de fallo es sobre-atribuir al AI. La mayoría de los colapsos en la ejecución de agentes onchain provienen del cableado, no de que el modelo elija el lado equivocado. Si la billetera del agente puede firmar un permiso amplio, o si las reglas del pagador son demasiado laxas, el sistema puede hacer exactamente lo que fue autorizado a hacer, y aún así ser inaceptable.

El resumen de compromisos es directo. Los EOAs son simples y directos, pero ponen todo el sistema detrás de una clave. ERC-4337 añade agrupamiento, validación personalizada y gas patrocinado, pero introduce una cadena de suministro de transacciones con bundlers, EntryPoint y pagadores opcionales. Safe añade fricción por diseño, y esa fricción es el punto cuando el tamaño importa.

Cerca del final de cualquier documento de arquitectura serio, el tema más amplio sigue siendo la ejecución autónoma onchain, y la pregunta es qué riel y qué capa de política el sistema puede realmente soportar bajo estrés.

La conclusión

He visto equipos obsesionarse con la parte de "AI" y luego cometer el costoso error: una aprobación de token amplia y de larga duración emparejada con una infraestructura frágil. Cuando algo sale mal, rara vez es porque el modelo alucinó un comercio. Es porque la capa de permisos permitió que un gastador retirara más de lo previsto, o porque la cadena de suministro ERC-4337 se detuvo en el bundler y nadie estaba monitoreando la inclusión.

La postura limpia es tratar esto como un diagrama de dos claves cada vez: autoridad de ejecución y autoridad de gasto. Si el diseño no puede responder, en una oración, quién origina la transacción (EOA vs bundler a través de EntryPoint) y exactamente qué puede retirar el gastador (monto, expiración, alcance de nonce), entonces el sistema no es “autónomo.” Simplemente está desatendido.

Fuentes

• QuickNode
• Eco
• Uniswap
• Safe