Cuando las carteras comienzan a incorporar agentes de IA: ¿Por qué vale la pena prestar atención a la nueva paradigma de interacción ERC-8211?

A partir de 2025, muchas personas quizás comenzarán a acostumbrarse a una nueva forma de interacción: decirle a GPT o Gemini una frase como “Ayúdame a planificar el viaje a Hong Kong la próxima semana y recomiéndame vuelos y hoteles adecuados”, y este realizará silenciosamente en segundo plano búsquedas de información, filtrado de condiciones, selección de rutas, comparación de precios y otros pasos, entregándote finalmente solo los resultados para que los confirmes.

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

Por ejemplo, si das una orden a un Agente DeFi: “Cambia ETH en la cartera por USDC, transfiere a la cadena Base, y deposítalo en Aave en su totalidad”, objetivamente, desde la “comprensión de la necesidad” y la “planificación de la ruta”, el Agente actual quizás no sea incapaz, pero la verdadera brecha aparece en la etapa de ejecución:

Aún es muy probable que tengas que completar paso a paso firmas, autorizaciones, intercambios, transferencias entre cadenas y depósitos, y cada paso está expuesto a riesgos como cambios en el deslizamiento, fluctuaciones en el Gas, retrasos en puentes y cambios en el estado en la cadena, lo que significa que si alguna parte se desvía de lo esperado, las acciones anteriores quizás no puedan revertirse, y las siguientes no puedan continuar, dejando al final en la cadena solo un proceso incompleto o en medio de ejecución.

El problema no radica en que la IA no sea lo suficientemente inteligente, sino en que la capa de ejecución en la cadena aún carece de una forma de expresión verdaderamente compatible con los Agentes.

Y precisamente por eso, en abril de 2026, Biconomy y la Fundación Ethereum lanzaron conjuntamente el ERC-8211, con el objetivo de resolver el problema de las “limitaciones estáticas” en la ejecución de contratos inteligentes, proporcionando una capa de ejecución más expresiva para los agentes de IA y flujos de trabajo DeFi complejos, intentando completar ese fragmento que falta.

I. La “última brecha” en la integración de Agentes IA en la cadena

En los últimos uno o dos años, la atención en la industria de las criptomonedas se ha desplazado claramente del escalado en L2, la liquidez de RWA, hacia cómo los Agentes IA realmente pueden tomar el control de las operaciones en la cadena, un tema bastante disruptivo.

Objetivamente, desde “emitir estrategias DeFi en múltiples pasos mediante lenguaje natural” hasta “que un Agente autónomo gestione un portafolio de inversión entre cadenas”, hemos visto muchas implementaciones prácticas, y la mayoría de estas ideas ya están maduras en fase de demostración, ya sea generando estrategias DeFi en múltiples pasos mediante lenguaje natural, reequilibrando automáticamente, migrando ganancias, ajustando posiciones entre cadenas, o incluso gestionando portafolios más complejos.

Desde la perspectiva de razonamiento y orquestación, la capacidad de la IA ha avanzado bastante, pero cuando realmente la llevamos a producción, las limitaciones en la capa de ejecución se vuelven cada vez más evidentes.

En producción, esta limitación puede resumirse en una frase: el DeFi es dinámico, pero la mayoría de los batch (procesamientos por lotes) actuales siguen siendo estáticos.

El sitio oficial y los foros del ERC-8211 explican claramente este problema: los ERC-4337 y EIP-5792 existentes ya han llevado el antiguo modelo de “una firma corresponde a una llamada” a una nueva etapa en la que “una firma puede empaquetar múltiples llamadas”, pero los parámetros en estas llamadas, en esencia, todavía están congelados en el momento de la firma.

Es decir, los valores que el usuario ingresa al firmar, como cantidades, objetivos o salidas esperadas, no se ajustarán automáticamente en tiempo de ejecución en función del estado en la cadena.

Pero el DeFi en sí mismo está lleno de incertidumbre. La salida real de un Swap depende del deslizamiento y la liquidez en el bloque en que se ejecuta; el tiempo y la cantidad final de una transferencia en un puente dependen del mecanismo y las tarifas del puente; la proporción de share a asset en protocolos de préstamo o Vault también cambia constantemente.

Al final, los valores que el usuario o el Agente ve al firmar muchas veces son solo estimaciones momentáneas, no resultados reales en el momento de la ejecución.

Para entender qué resuelve el ERC-8211, primero veamos un ejemplo típico: supongamos que un Agente quiere hacer algo muy simple — cambiar ETH en la cuenta por USDC, y depositarlo en Spark para ganar intereses.

Bajo el modelo actual de procesamiento estático por lotes, el Agente debe estimar cuánto USDC recibirá después del Swap antes de firmar, lo que a menudo obliga a codificar de antemano la cantidad de entrada en el segundo paso, y si la estimación es demasiado alta, la cantidad real recibida puede ser insuficiente, causando que toda la transacción se revierta; si la estimación es demasiado baja, puede quedar parte del dinero inactivo en la cartera sin poder usarse.

En otras palabras, se entra en una especie de dilema: asumir el riesgo de fallar, o sacrificar oportunidades. Por eso, cuando los procesos en la cadena se extienden a 5, 8 pasos o incluso cruzan varias cadenas, se vuelven rápidamente frágiles. No es que la estrategia sea demasiado compleja para describir, sino que el paradigma actual de ejecución depende demasiado de parámetros codificados de antemano.

En resumen, la capacidad máxima del batch estático determina en realidad el límite seguro de las estrategias que un Agente puede ejecutar.

Desde esta perspectiva, lo que busca resolver el ERC-8211 no es tanto cómo toman decisiones los Agentes IA, sino si, una vez que toman una decisión, existe una forma más natural, estable y segura de ejecutarla en la cadena. Para que la ejecución en la cadena tenga una primera expresión nativa diseñada para Agentes IA.

II. ¿Qué cambios trae realmente el ERC-8211?

El avance principal del ERC-8211 no radica en meter más pasos en una sola firma, sino en transformar el procesamiento por lotes, que antes era una secuencia de transacciones con parámetros codificados, en un “programa que evalúa dinámicamente los parámetros en tiempo de ejecución”.

Suena abstracto, pero no es difícil de entender: la descripción oficial dice: “De transacciones a programas”.

Esto significa que el ERC-8211 deja de considerar el batch como una lista de acciones que se ejecutan en orden, para verlo como un programa que se evalúa en tiempo de ejecución, con condiciones de seguridad. Específicamente, lo logra mediante tres primitivas combinables:

• Fetchers (obtenedores): definen de dónde obtener los valores de los parámetros, pudiendo ser consultas en tiempo real del saldo de una dirección, de modo que los parámetros ya no sean instantáneas en el momento de la firma, sino que se obtengan en tiempo de ejecución desde el estado en la cadena;
• Constraints (restricciones): después de extraer los valores, se verifican mediante restricciones en línea — por ejemplo, “USDC obtenido debe ser ≥ 2500”, o “el deslizamiento no puede superar el 0.5%”, y si alguna restricción no se cumple, toda la transacción se revierte inmediatamente;
• Predicates (predicados): actúan como guardianes entre pasos, no generan valores, sino que deciden si continuar o no, por ejemplo, en escenarios cross-chain, el batch en Ethereum puede estar bloqueado por un predicate que verifica “el WETH transferido desde el otro lado ya llegó”, y hasta que no se cumpla esa condición, no se envía la transacción.

En este diseño, cada parámetro debe responder a dos preguntas: primero, ¿de dónde obtiene su valor en tiempo de ejecución? y segundo, ¿qué condiciones debe cumplir antes de usarse en la llamada? La combinación de estos tres elementos hace que un batch deje de ser solo una lista de transacciones, para convertirse en un programa con verificaciones de seguridad integradas.

En definitiva, el modelo mental del batch estático es una lista — ejecutar A, luego B, luego C —, mientras que el modelo del ERC-8211 es un programa con condiciones — después de ejecutar A, usar su salida real como entrada para B; B debe cumplir restricciones antes de pasar a C; si alguna no se cumple, toda la transacción se revierte.

Podemos entenderlo como un mecanismo de “batch inteligente” diseñado específicamente para Agentes IA y operaciones DeFi complejas, porque en la operación tradicional en cadena, completar una estrategia DeFi compleja requiere múltiples transacciones independientes: retirar fondos de un protocolo de préstamo, intercambiar tokens, depositar en otro protocolo, etc. (ver también “Visión general del protocolo de IA en criptomonedas: desde el campo de batalla en Ethereum, cómo construir un sistema operativo para Agentes IA”).

Cada paso requiere firma y confirmación por separado, lo cual ya es engorroso para usuarios humanos, y aún más para Agentes IA que operan a alta frecuencia. La solución del ERC-8211 es permitir que múltiples operaciones en diferentes cadenas se combinen en una sola transacción, y que cada paso, en tiempo de ejecución, analice dinámicamente los valores reales, y solo continúe si se cumplen las condiciones predefinidas.

Por ejemplo, un Agente puede en una sola firma: retirar fondos de Aave → intercambiar la cantidad recibida en Uniswap → depositar el resultado en Compound — todo de forma atómica, sin necesidad de crear nuevos contratos inteligentes.

III. ¿Por qué tiene una relación más importante con las carteras, especialmente las carteras inteligentes?

El motivo por el que el ERC-8211 merece la atención de la industria de carteras no es solo porque sea adecuado para Agentes, sino porque redefine la posición de las carteras en la interacción en cadena.

Las carteras tradicionales, más que nada, son firmantes seguros: almacenan claves privadas, muestran transacciones, piden confirmación y envían firmas. Este rol fue suficiente en la era de las cuentas externas (EOA), y sigue siendo válido en la era de la abstracción de cuentas, pero si en el futuro muchas operaciones en cadena las realiza un Agente en lugar del usuario, el papel de la cartera será aún más central y relevante.

La razón es simple: cuando el usuario ya no controla cada acción en la cadena, sino que autoriza a un Agente para que ejecute un conjunto completo de objetivos, la cartera debe ser capaz de gestionar este nivel superior de interacción. Ya no solo mostrará una dirección de contrato y un fragmento de calldata, sino toda una “intención — lógica de obtención — condiciones — resultado final” como un programa ejecutable.

Por lo tanto, las carteras del futuro deben entender no solo transacciones, sino programas. El ERC-8211 proporciona en este nivel una herramienta más clara, porque codifica explícitamente estas semánticas de ejecución: de dónde vienen los parámetros, qué condiciones deben cumplirse, cuándo continuar, cuándo revertir. Todo esto no es un “caja negra” en la lógica tras bambalinas, sino objetos que la cartera puede interpretar, simular y mostrar.

Desde la perspectiva de la cartera, todo este mecanismo apunta a una misma idea: el usuario ya no firma una serie de llamadas subyacentes que no puede entender completamente, sino que firma un programa de ejecución con resultados claros, límites definidos y condiciones verificables:

• El Agente IA puede entender la intención del usuario y generar la ruta;
• La cartera puede mostrar esa ruta de forma más comprensible para que el usuario la revise;
• El relayer solo envía la transacción cuando se cumplen las condiciones, sin poder alterar el resultado.

Este es el motivo por el cual la ejecución sin custodia (non-custodial) basada en Agentes se considera un prerrequisito para el DeFi con carácter de agente, porque la inteligencia puede participar, pero la soberanía, las restricciones y la liquidación final permanecen en la cadena. Y esto es precisamente donde el ERC-8211 encaja con las carteras inteligentes: incorpora la “expresión segura de intenciones complejas” en el estándar del protocolo.

Cabe destacar que el ERC-8211 es compatible con otros marcos de abstracción de cuentas como ERC-4337, EIP-7702, ERC-7579, no los reemplaza, sino que añade una capa de semántica programática a la abstracción de cuentas.

Si el ERC-4337 resolvió “quién puede iniciar una transacción en mi nombre”, y el EIP-7702 resolvió “cómo una EOA puede tener temporalmente capacidades de contrato inteligente”, el ERC-8211 resuelve: una vez que un Agente empieza a actuar en mi nombre, ¿puede completar toda la cadena de decisiones en una sola firma?

Reflexionando sobre la evolución del paradigma de interacción en Ethereum en los últimos 10 años:

• Primera etapa: firma única = llamada a función única (era EOA)
• Segunda etapa: firma única = paquete de llamadas estáticas (ERC-4337, EIP-5792)
• Tercera etapa: firma única = programa de intención con evaluación dinámica (ERC-8211)

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

Aunque el ERC-8211 aún está en fase de borrador, con discusiones técnicas en curso, y su integración a gran escala aún requiere tiempo, la dirección ya está clara: cuando los Agentes IA comiencen a tomar decisiones en cadena, será necesario un lenguaje de ejecución nativo en la cadena que se adapte a ellos.