A partir de 2025, muchas personas quizás comiencen a acostumbrarse gradualmente a una nueva forma de interactuar: decirle a GPT o Gemini "Ayúdame a planificar un viaje a Hong Kong para la próxima semana y recomienda vuelos y hoteles adecuados", y este completará en segundo plano una serie de pasos como búsqueda de información, filtrado de condiciones, selección de rutas, comparación de precios, etc., para finalmente entregarte solo los resultados para su confirmación.
Sin embargo, si llevamos la misma expectativa a la cadena, la historia cambia por completo.
Por ejemplo, si le das una instrucción a un Agente DeFi: "Cambia el ETH de mi cartera por USDC, transfiérelo a la cadena Base y luego deposítalo en su totalidad en Aave". Objetivamente hablando, en términos de "comprender la necesidad" y "planificar la ruta", los Agentes actuales no necesariamente no pueden hacerlo; la verdadera brecha aparece en la ejecución:
Es muy probable que aún tengas que completar paso a paso operaciones como firmar, autorizar, intercambiar, realizar cross-chain y depositar, y cada paso está expuesto a riesgos como cambios en el slippage, fluctuaciones del Gas, retrasos en el puente y cambios en el estado de la cadena. Esto significa que si algún eslabón intermedio se desvía de lo esperado, las acciones anteriores pueden no poder revertirse, y las acciones posteriores podrían no conectarse, dejando finalmente en la cadena solo un flujo de proceso a medio hacer.
El problema no es que la IA no sea lo suficientemente inteligente, sino que la capa de ejecución en la cadena aún carece de una forma de expresión verdaderamente adaptada a los Agentes.
Precisamente por eso, a principios de abril de 2026, Biconomy y la Fundación Ethereum publicaron conjuntamente ERC-8211, que tiene como objetivo resolver el problema de las "limitaciones estáticas" en la ejecución actual de contratos inteligentes, proporcionando una capa de ejecución más expresiva para agentes de IA y flujos de trabajo DeFi complejos, intentando completar esta pieza faltante del rompecabezas.
一、La "última brecha" para la conexión del AI Agent a la cadena
En el último año o dos, el foco de atención de la industria cripto se ha desplazado claramente de la expansión de L2, la liquidez de RWA, hacia el tema disruptivo de cómo los Agentes de IA pueden realmente hacerse cargo de las operaciones en cadena.
Objetivamente, desde "ejecutar estrategias DeFi de múltiples pasos con lenguaje natural" hasta "permitir que un Agente autónomo gestione toda una cartera de inversión cross-chain", recientemente hemos visto muchas prácticas, y la mayoría de las ideas ya están maduras a nivel de demo, ya sea la generación de estrategias DeFi de múltiples pasos a partir de lenguaje natural, la ejecución autónoma de rebalanceo, la migración automática de rendimientos, el ajuste de posiciones cross-chain, e incluso una gestión de carteras más compleja.
Desde la perspectiva del razonamiento y la orquestación, la capacidad de la IA ha avanzado bastante rápido, pero cuando realmente se la lleva a un entorno de producción, las deficiencias de la capa de ejecución se vuelven cada vez más evidentes.
Si realmente se lleva a un entorno de producción, esta deficiencia se puede resumir en una frase: DeFi es dinámico, pero la mayoría de los batch (procesamiento por lotes) de hoy siguen siendo estáticos.
Tanto el sitio web de ERC-8211 como los posts de discusión dejan claro este problema: los actuales ERC-4337 y EIP-5792, ciertamente han llevado el antiguo modelo de "una firma corresponde a una llamada" a una nueva etapa de "una firma puede empaquetar múltiples llamadas", pero los parámetros en estas llamadas, en esencia, todavía se congelan en el momento de la firma.
Es decir, el monto, el valor objetivo, la salida esperada que el usuario ingresa al firmar, no se ajustan automáticamente cuando se ejecutan realmente, debido a los cambios de estado en la cadena.
Pero el DeFi en sí está lleno de incertidumbre. La salida real de un Swap depende del slippage y la liquidez en el bloque donde se ejecuta; el tiempo de llegada y el monto final de un Bridge dependen del mecanismo y las tarifas del puente mismo; la relación share-to-asset de un protocolo de préstamo o Vault también cambia constantemente.
Después de todo, los valores que el usuario o el Agente ven al firmar, muchas veces son solo una estimación momentánea, no el resultado real en el momento de la ejecución.
Para entender qué resuelve ERC-8211, primero veamos un ejemplo típico: supongamos que un Agente quiere hacer algo que parece muy común: cambiar el ETH de la cuenta por USDC y luego depositarlo en su totalidad en Spark para ganar intereses.
Bajo el modelo estático de procesamiento por lotes existente, el Agente debe estimar cuánto USDC obtendrá después del Swap antes de firmar, lo que a menudo te obliga a escribir por adelantado el monto de entrada para el segundo paso en el momento de la firma. Si estimas demasiado alto, la cifra real recibida no es suficiente y todo el lote se revierte directamente; si estimas demasiado bajo, dejarás una parte de los fondos inactivos en la cartera, sin poder hacer nada.
En otras palabras, básicamente te encuentras en el llamado dilema: asumir el riesgo de fracaso o asumir el costo de oportunidad. Es por eso que muchos flujos en cadena que no parecen complejos, una vez que los pasos se extienden a 5, 8 pasos, o incluso cruzan dos cadenas, se vuelven rápidamente frágiles. Esto no se debe a que la estrategia en sí sea demasiado compleja de describir, sino a que el paradigma de ejecución existente depende demasiado de parámetros predefinidos.
En resumen, el límite de capacidad del procesamiento por lotes estático determina, de hecho, el límite superior de las estrategias que un Agente puede ejecutar de forma segura.
Desde esta perspectiva, lo que ERC-8211 intenta resolver no es cómo toma decisiones el AI Agent, sino que, una vez que el Agente ya ha tomado una decisión, si existe en la cadena una forma más natural, estable y segura de ejecutarla. Haciendo que la ejecución en cadena tenga por primera vez una forma de expresión diseñada de forma nativa para los Agentes de IA.
二、¿Qué cambia realmente ERC-8211?
El avance central de ERC-8211 no reside en meter más pasos en una firma, sino en actualizar el procesamiento por lotes de una secuencia de transacciones con parámetros fijos a un "programa" cuyos "parámetros se evalúan dinámicamente en el sitio de ejecución".
Suena muy abstracto, pero no es difícil de entender. Los oficiales usaron una frase para describirlo: De transacciones a programas.
Esto significa que ERC-8211 ya no ve un lote como una lista de acciones a ejecutar en secuencia, sino como un programa de ejecución que se evalúa en tiempo de ejecución y lleva condiciones de seguridad. Desglosándolo concretamente, logra esto a través de tres primitivas componibles:
- Fetchers (Obtenedores de valor): Definen de dónde se obtiene el valor para este parámetro. Puede ser una consulta al 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 capturada del estado de la cadena en el instante de la ejecución.
- Constraints (Restricciones): Después de que el parámetro se resuelve, debe pasar una verificación de restricción en línea, por ejemplo, "el USDC obtenido debe ser ≥ 2500" o "el slippage no puede exceder el 0.5%". Estas restricciones se validan antes de que el valor se enrute a la siguiente llamada. Si alguna no se cumple, todo el lote se revierte inmediatamente.
- Predicates (Condiciones desencadenantes): Pueden entenderse como guardianes entre pasos. No son responsables de producir valores, sino de juzgar si continuar la ejecución. Por ejemplo, en un escenario cross-chain, el lote en el lado de Ethereum puede usar un predicate para esperar a que se cumpla la condición de que "el WETH transferido cross-chain ya ha llegado", y no se envía hasta que llegue.
En este diseño, cada parámetro debe responder dos preguntas: Primera, ¿de dónde debe venir este valor en el momento de la ejecución? Segunda, ¿qué condiciones debe cumplir antes de ser utilizado realmente en la llamada? Combinadas estas tres, un lote ya no es solo una secuencia de transacciones, sino un programa con controles de seguridad integrados.
En resumen, el modelo mental del procesamiento por lotes estático es una lista: ejecutar los pasos A, B, C en secuencia; mientras que el modelo mental de ERC-8211 es un programa con condiciones: después de ejecutar A, toma la salida real de A como entrada de B; B debe satisfacer las restricciones para pasar a C; si cualquier paso no cumple las expectativas, todo el lote se revierte.
Realmente podemos entenderlo simplemente como un mecanismo de "procesamiento por lotes inteligente" diseñado específicamente para Agentes de IA y operaciones DeFi complejas. Porque en las operaciones tradicionales en cadena, completar una estrategia DeFi compleja a menudo requiere múltiples transacciones independientes: extraer fondos de un protocolo de préstamo, intercambiar tokens, depositarlos en otro protocolo (lectura extendida "Panorama de los protocolos de IA cripto: partiendo del campo de batalla principal de Ethereum, ¿cómo construir un nuevo sistema operativo para los Agentes de IA?").
Cada paso requiere una firma y confirmación separada, lo que ya es tedioso para los usuarios humanos, y es un cuello de botella aún mayor para los Agentes de IA que necesitan operar de forma autónoma y de alta frecuencia. La solución de ERC-8211 es permitir que múltiples operaciones blockchain se ejecuten combinadas en una sola transacción, donde cada paso analiza dinámicamente los valores reales durante la ejecución, y debe cumplir condiciones predefinidas antes de pasar al siguiente paso.
Por ejemplo, un Agente puede completar en una transacción firmada: extraer fondos de Aave → intercambiar el monto realmente recibido en Uniswap → depositar el resultado del intercambio en Compound, todo ejecutado atómicamente, sin necesidad de escribir un nuevo contrato inteligente.
三、¿Por qué se dice que está más relacionado con las carteras, especialmente las carteras inteligentes?
La razón por la que ERC-8211 merece la atención de la industria de las carteras no es solo porque sea adecuado para los Agentes, sino porque redefinirá la posición de la cartera en la cadena de interacción.
Las carteras del pasado se parecían más a un firmante de seguridad. Su responsabilidad era custodiar la clave privada, mostrar la transacción, que el usuario la confirmara y luego enviar la firma. Este papel ya era lo suficientemente importante en la era EOA y sigue siéndolo en la era de la abstracción de cuentas. Pero si en el futuro cada vez más operaciones en cadena las realizan Agentes en su nombre, el papel de la cartera se volverá más central y pesado.
La razón es simple: cuando los usuarios ya no controlan las acciones en cadena transacción por transacción, sino que comienzan a autorizar a un Agente para que ejecute un conjunto completo de objetivos, la cartera debe tener la capacidad de manejar este objeto de interacción de nivel superior. Lo que debe mostrar ya no es solo una dirección de contrato y un calldata, sino un programa de ejecución completo de "intención — lógica de obtención de valor — juicio condicional — resultado final".
Por lo tanto, la cartera del futuro necesita entender, ya no solo transacciones, sino programas. ERC-8211 proporciona precisamente a las carteras un punto de apoyo más claro en este nivel, porque escribe explícitamente estas semánticas de ejecución en la estructura de codificación. Incluyendo de dónde vienen los parámetros, qué condiciones deben cumplir, cuándo continuar, cuándo revertir, no son una caja negra oculta en la lógica del backend, sino un objeto que la cartera puede interpretar, simular y mostrar.
Desde la perspectiva de la cartera, todo este mecanismo apunta finalmente a lo mismo: el usuario ya no está firmando una serie de llamadas de bajo nivel que le cuesta entender por completo, sino firmando un programa de ejecución orientado a resultados, con límites claros y condiciones verificables:
- El AI Agent puede ser responsable de entender la intención del usuario y generar la ruta;
- La cartera es responsable de mostrar esta ruta de una manera más clara para que el usuario la revise;
- Y el relayer solo es responsable de enviar la transacción cuando se cumplan las condiciones, sin tener permiso para alterar el resultado;
Esta es precisamente la razón por la que la ejecución no custodiada es considerada un requisito previo para el DeFi Agéntico: porque el agente puede participar, pero la soberanía, las restricciones y la liquidación final permanecen en la cadena. Este es también el lugar donde ERC-8211 y las carteras inteligentes encajan realmente: es que escribe en el estándar de la capa de protocolo la "expresión segura de intenciones complejas".
Vale la pena mencionar que ERC-8211 es totalmente compatible con marcos de abstracción de cuentas como ERC-4337, EIP-7702, ERC-7579, etc. No reemplaza la abstracción de cuentas, sino que, sobre la abstracción de cuentas, añade una capa de semántica de ejecución programática para los Agentes.
Si ERC-4337 resolvió "quién puede representarme para iniciar una transacción", EIP-7702 resolvió "cómo una EOA puede tener temporalmente capacidades de contrato inteligente", entonces ERC-8211 resuelve: una vez que el Agente comienza a operar por mí, ¿puede completar una cadena de decisión completa con una sola firma?
Mirando hacia atrás en la evolución del paradigma de interacción en cadena de Ethereum en los últimos 10 años:
- Primera etapa: una firma = una llamada de función (era EOA)
- Segunda etapa: una firma = un conjunto de llamadas empaquetadas estáticamente (era ERC-4337, EIP-5792)
- Tercera etapa: una firma = un programa de intención de evaluación dinámica (era ERC-8211)
Cada transición significa que el usuario (o el Agente que lo representa) puede expresar objetivos más complejos con menos fricción.
Aunque ERC-8211 todavía se encuentra en etapa de borrador, la discusión técnica aún está en curso, y la adopción a gran escala por parte de los protocolos también llevará tiempo, la dirección que señala ya es lo suficientemente clara: cuando los Agentes de IA realmente comiencen a tomar decisiones en cadena por las personas, la cadena necesitará una sintaxis de ejecución nativa que coincida con ello.
