ERC-8211 busca habilitar la ejecución dinámica para agentes de IA en DeFi

A partir de 2025, muchas personas podrían acostumbrarse gradualmente a un nuevo método de interacción: decirle a GPT o Gemini «Planifica mi viaje a Hong Kong la próxima semana y recomiéndame vuelos y hoteles adecuados», y este realizará en segundo plano una serie de pasos, como buscar información, filtrar condiciones, elegir rutas y comparar precios, para finalmente entregarte solo los resultados para que los confirmes.

Sin embargo, llevar las mismas expectativas a la cadena cambia completamente la historia.

Por ejemplo, si le das una instrucción a un Agente DeFi: «Cambia los ETH de tu billetera por USDC, transfiérelos a la cadena Base y luego deposita el monto total en Aave». Objetivamente, desde la perspectiva de «comprender la necesidad» y «planificar la ruta», hoy en día un Agente no necesariamente es incapaz de hacerlo; la verdadera brecha se presenta en la fase de ejecución:

Aún es muy probable que debas completar paso a paso operaciones como firma, autorización, intercambio, puente cruzado y depósito, y cada paso está expuesto al riesgo de cambios en el deslizamiento, fluctuaciones de Gas, retrasos en el puente y cambios en el estado de la cadena. Esto significa que si cualquier etapa se desvía de lo esperado, las acciones anteriores podrían no ser reversibles y las siguientes podrían no conectarse, dejando al final en la cadena solo un proceso incompleto.

El problema no es que la IA no sea lo suficientemente inteligente, sino que la capa de ejecución en cadena aún carece de una forma verdaderamente adaptada para Agentes.

Por esta razón, a principios de abril de 2026, Biconomy y la Ethereum Foundation lanzaron conjuntamente la ERC-8211, diseñada para abordar las "limitaciones estáticas" actuales en la ejecución de contratos inteligentes, proporcionando una capa de ejecución más expresiva para agentes de IA y flujos de trabajo DeFi complejos, con el objetivo de completar este fragmento perdido del rompecabezas.

Durante los últimos uno o dos años, el foco de atención de la industria cripto ha pasado claramente de la escalabilidad L2 y la liquidez RWA hacia el tema profundamente disruptivo de cómo los agentes de IA pueden tomar el control real de las operaciones en cadena.

Objetivamente, recientemente también hemos visto numerosas implementaciones, desde "emitir estrategias DeFi de múltiples pasos mediante lenguaje natural" hasta "permitir que agentes autónomos gestionen una cartera completa entre cadenas", y la mayoría de estas ideas ya están maduras a nivel de demostración, ya sea la generación de estrategias DeFi de múltiples pasos mediante lenguaje natural, la ejecución autónoma de reequilibrio, la migración automática de rendimientos, el ajuste de posiciones entre cadenas o incluso la gestión de carteras más complejas.

Desde la perspectiva del razonamiento y la planificación, la capacidad de la IA ya ha avanzado bastante, pero cuando realmente se implementa en un entorno de producción, las deficiencias en la capa de ejecución se vuelven cada vez más evidentes.

Cuando se implemente en producción, esta debilidad se puede resumir en una frase: DeFi es dinámico, pero la mayoría de los batch (lotes) de hoy aún son estáticos.

El sitio web oficial de ERC-8211 y la publicación de discusión explican claramente este problema: ERC-4337 y EIP-5792 actuales han avanzado desde el modelo antiguo de «una firma por una llamada» hacia la nueva etapa de «una firma puede empaquetar múltiples llamadas», pero los parámetros dentro de estas llamadas siguen estando esencialmente congelados en el momento de la firma.

Es decir, la cantidad, el valor objetivo y el resultado esperado ingresados por el usuario al firmar no se ajustarán automáticamente debido a cambios en el estado de la cadena al momento de la ejecución.

Pero el mismo DeFi es precisamente incierto. La salida real de un Swap depende del slippage y la liquidez dentro del bloque en que se ejecuta; el tiempo de llegada y el monto final de una Bridge dependen del mecanismo y las tarifas de la propia puente; la relación share-to-asset de los protocolos de préstamo o Vault también cambia constantemente.

Después de todo, el valor que el usuario o el agente ven al firmar a menudo es solo una estimación en ese momento, no el resultado real al ejecutarse.

Para entender qué resuelve ERC-8211, primero veamos un ejemplo típico: supongamos que un Agente quiere realizar una acción que parece muy común, como intercambiar el ETH de su cuenta por USDC y depositar el monto total en Spark para generar intereses.

Bajo el modelo actual de procesamiento por lotes estático, el agente debe estimar previamente cuánto USDC recibirá después del intercambio, lo que a menudo obliga a fijar de antemano la cantidad de entrada para el segundo paso al firmar; si la estimación es demasiado alta y el monto real recibido es insuficiente, todo el lote se revierte; si es demasiado baja, parte del capital permanece inactivo en la billetera sin poder utilizarse.

En otras palabras, se cae en lo que se conoce como un dilema: asumir el riesgo de fracaso o el costo de oportunidad. Por eso, muchos procesos en cadena que parecen no ser complejos se vuelven rápidamente frágiles cuando se extienden a 5, 8 pasos o incluso cruzan dos cadenas; no porque la estrategia en sí sea demasiado compleja para describirla, sino porque el modelo de ejecución actual depende demasiado de parámetros predefinidos.

En resumen, el límite de capacidad del batch estático determina de hecho el límite superior de las estrategias que el Agente puede ejecutar de forma segura.

Desde este punto de vista, ERC-8211 busca resolver no cómo los Agentes de IA toman decisiones, sino si existe en la cadena una forma más natural, estable y segura de ejecutarlas una vez que ya se han tomado. Así, la ejecución en cadena adquiere por primera vez una forma de expresión nativa para Agentes de IA.

El avance clave de ERC-8211 no consiste en empacar más pasos en una sola firma, sino en elevar el procesamiento por lotes de una secuencia de transacciones con parámetros codificados estáticamente a un «programa cuyos parámetros se evalúan dinámicamente en tiempo de ejecución».

Suena bastante abstracto, pero no es difícil de entender; la oficina lo describió con una frase: From transactions to programs.

Esto significa que ERC-8211 ya no considera el batch como una lista de acciones ejecutadas en orden, sino como un programa de ejecución evaluado en tiempo de ejecución con condiciones de seguridad; específicamente, lo logra mediante tres primitivas combinables:

• Fetchers: Definen desde dónde se obtiene este parámetro; puede ser una consulta del saldo actual de una dirección, haciendo que el parámetro ya no sea una instantánea en el momento de la firma, sino una lectura en tiempo real obtenida del estado de la cadena en el momento de la ejecución;
• Constraints: Una vez extraídos los parámetros, se deben realizar comprobaciones de restricciones en línea — por ejemplo, «el USDC recibido debe ser ≥ 2500» o «el slippage no puede superar el 0,5%»; estas restricciones se verifican antes de que los valores se enruten a la siguiente llamada, y si alguna falla, todo el lote se revierte inmediatamente;
• Predicados (condiciones de activación): Se pueden entender como guardias entre los pasos, que no generan valores, sino que determinan si continuar la ejecución; por ejemplo, en un escenario de puente entre cadenas, el batch en el lado de Ethereum puede quedarse esperando en el predicado hasta que se confirme que el WETH transferido desde otra cadena ha llegado, y no enviarlo hasta que eso ocurra;

En este diseño, cada parámetro debe responder a dos preguntas: primero, de dónde proviene este valor al ejecutarse; segundo, qué condiciones debe cumplir antes de ser utilizado realmente en la llamada, de modo que, combinados estos tres elementos, un lote ya no sea simplemente una secuencia de operaciones, sino un programa con comprobaciones de seguridad integradas.

En última instancia, el modelo mental del procesamiento por lotes estático es una lista: ejecutar los pasos A, B y C en orden; mientras que el modelo mental de ERC-8211 es un programa condicional: después de ejecutar A, tomar la salida real de A como entrada para B; B solo avanza a C si cumple las restricciones; si cualquier paso no alcanza el resultado esperado, todo el lote se revierte.

En realidad, podemos entenderlo simplemente como un mecanismo de «procesamiento por lotes inteligente» diseñado específicamente para AI Agent y operaciones complejas de DeFi, ya que en las operaciones tradicionales en cadena, llevar a cabo una estrategia compleja de DeFi generalmente requiere múltiples transacciones independientes: retirar fondos de un protocolo de préstamo, intercambiar tokens y volver a depositarlos en otro protocolo (lectura adicional: Visión general de los protocolos de IA criptográfica: desde el campo de batalla principal de Ethereum, ¿cómo construir un nuevo sistema operativo para AI Agent?).

Cada paso requiere una firma y confirmación separadas, lo cual es already tedioso para los usuarios humanos y un cuello de botella para los AI Agentes que necesitan operaciones autónomas de alta frecuencia; la solución de ERC-8211 permite combinar múltiples operaciones de blockchain en una sola transacción, resolviendo dinámicamente los valores reales en cada paso y requiriendo que se cumplan condiciones predefinidas antes de avanzar al siguiente paso.

Por ejemplo, un agente puede completar esto en una sola transacción firmada: retirar fondos de Aave → intercambiar el monto recibido en Uniswap → depositar el resultado del intercambio en Compound—todo ejecutado de forma atómica, sin necesidad de escribir un nuevo contrato inteligente.

ERC-8211 merece la atención de la industria de billeteras no solo porque es adecuada para Agentes, sino porque redefinirá el papel de las billeteras en la cadena de interacción.

Los billeteras del pasado eran más bien firmadores seguros, cuya función era guardar las claves privadas, mostrar transacciones, permitir al usuario confirmarlas y luego enviar las firmas; este rol fue suficientemente importante en la era EOA y sigue siendo válido en la era de la abstracción de cuentas, pero si en el futuro un número creciente de operaciones en cadena son realizadas por Agentes, el papel de la billetera se volverá aún más central y crucial.

La razón es sencilla: cuando los usuarios ya no manipulan manualmente cada acción en la cadena, sino que autorizan a un Agente para ejecutar un conjunto completo de objetivos, la billetera debe tener la capacidad de gestionar este tipo de interacción de nivel superior. Ya no solo debe mostrar una dirección de contrato y un fragmento de calldata, sino todo un programa de ejecución que comprende: «intención—lógica de valoración—evaluación condicional—resultado final».

Por lo tanto, las billeteras del futuro necesitan comprender no solo transacciones, sino programas. ERC-8211 proporciona en este nivel a las billeteras un punto de agarre más claro, ya que incorpora explícitamente estas semánticas de ejecución en la estructura codificada: de dónde provienen los parámetros, qué condiciones deben cumplirse, cuándo continuar y cuándo revertir, todo ello no es un black box oculto en la lógica del backend, sino un objeto que puede ser interpretado, simulado y mostrado por la billetera.

Desde la perspectiva de la billetera, todo este mecanismo apunta finalmente a lo mismo: el usuario ya no está firmando una serie de llamadas subyacentes que difícilmente puede comprender por completo, sino un programa de ejecución orientado a resultados, con límites claros y condiciones verificables:

• El agente de IA puede encargarse de comprender la intención del usuario y generar la ruta;
• La billetera se encarga de mostrar esta ruta al usuario de manera más clara para su revisión;
• Y el relayer solo se encarga de enviar la transacción cuando se cumplen las condiciones, sin tener permiso para alterar los resultados;

Esta es precisamente la razón por la que la ejecución no custodiada se considera un prerequisito para el Agentic DeFi, ya que los agentes pueden participar, pero la soberanía, las restricciones y el cierre final permanecen en la cadena, lo que hace que ERC-8211 encaje perfectamente con los billeteras inteligentes, ya que incorpora en el estándar de la capa de protocolo la capacidad de «expresar de forma segura intenciones complejas».

Es importante destacar que ERC-8211 es completamente compatible con marcos de abstracción de cuenta como ERC-4337, EIP-7702 y ERC-7579; no reemplaza la abstracción de cuenta, sino que añade una capa adicional de semántica de ejecución programática para Agentes sobre la abstracción de cuenta.

Si ERC-4337 resuelve "quién puede representarme para iniciar una transacción" y EIP-7702 resuelve "cómo un EOA puede adquirir temporalmente capacidades de contrato inteligente", entonces ERC-8211 resuelve si un Agente, una vez que comience a operar en mi nombre, puede completar toda una cadena de decisiones en una sola firma.

Repasar la evolución de los patrones de interacción en la cadena de Ethereum durante los últimos 10 años:

• Fase uno: Una firma = una llamada a función (era EOA)
• Fase dos: Una firma = un conjunto de llamadas empaquetadas estáticas (era ERC-4337, EIP-5792)
• Fase tres: Una firma = un programa de intención evaluado dinámicamente (era ERC-8211)

Cada salto implica que el usuario (o el agente que lo representa) puede expresar objetivos más complejos con menos fricción.

Aunque ERC-8211 aún se encuentra en fase de borrador y las discusiones técnicas continúan, así como también se requiere más tiempo para la integración a gran escala del protocolo, la dirección que indica ya es lo suficientemente clara: cuando los AI Agent realmente comiencen a tomar decisiones en cadena en nombre de las personas, la cadena necesitará una sintaxis nativa y adecuada para ello.