ERC-8211 Smart Batching: Cómo Biconomy y la Ethereum Foundation acaban de reescribir las reglas para los agentes de IA on-chain

El 7 de abril de 2026, Biconomy y la Fundación Ethereum publicaron discretamente una propuesta que podría resultar ser el estándar de infraestructura de agentes más trascendental desde el ERC-4337 . Se llama ERC-8211 y, a primera vista, parece una actualización de contabilidad: una nueva forma de codificar transacciones por lotes (batch transactions). Al observar más de cerca, se trata de algo mucho mayor — la primera respuesta a nivel de protocolo a una pregunta que ha perseguido a la IA on-chain durante dos años: ¿cómo transacciona realmente un agente autónomo de forma segura en Ethereum sin que el usuario firme cada uno de los movimientos?

El momento no es accidental. Con aproximadamente 62 millones de cuentas inteligentes (smart accounts) activas en las cadenas EVM, 2,4 mil millones de UserOperations procesadas acumuladas y una población en rápido crecimiento de agentes autónomos que ejecutan estrategias DeFi reales en nombre de los usuarios, Ethereum ha alcanzado el límite de lo que las transacciones por lotes estáticas pueden expresar. El ERC-8211 — denominado "smart batching" o procesamiento por lotes inteligente — es el estándar diseñado para romper ese techo.

El problema que el batching estático no pudo resolver

Durante los últimos dos años, el ERC-4337 y el EIP-5792 han realizado el trabajo pesado para las transacciones por lotes. Permiten que una cuenta inteligente agrupe múltiples llamadas bajo una sola firma: aprobar un token, intercambiarlo en Uniswap, depositar las ganancias en Aave, todo de forma atómica. Ese modelo funciona de maravilla — hasta que recuerdas que DeFi es un objetivo en constante movimiento.

Los flujos reales de DeFi producen resultados dinámicos e impredecibles. Un intercambio (swap) podría devolver 1,000 USDC o 998 USDC dependiendo del deslizamiento (slippage). El retiro de una bóveda (vault) podría generar el capital principal más 23.4 dólares de intereses acumulados, o 23.7. El batching estático obliga a los desarrolladores y agentes a elegir entre dos malas opciones:

• Codificar montos optimistas de forma rígida (hardcode) — y ver cómo todo el lote se revierte cuando la realidad no alcanza la expectativa.
• Subestimar de forma conservadora — y dejar valor varado en pasos intermedios que la siguiente llamada no puede alcanzar.

De cualquier manera, el usuario paga el costo: transacciones fallidas, capital bloqueado o rendimientos subóptimos. Para un agente de IA que opera sin supervisión, esto es peor que ineficiente. Es operativamente insostenible. Un agente que tiene que despertar al usuario cada vez que un swap devuelve una cantidad inesperada no es un agente — es un Slackbot con una billetera.

El ERC-8211 soluciona esto introduciendo tres primitivas que convierten un lote de una "receta congelada" en un "programa con controles de seguridad integrados".

Los tres bloques de construcción: Fetchers, Constraints y Predicates

El genio del ERC-8211 reside en su compacidad. No intenta ser una máquina virtual. Añade exactamente tres cosas al formato de lote existente y deja que el resto de la infraestructura — bundlers de ERC-4337, autorizaciones de EIP-7702, cuentas modulares ERC-7579 — se encargue del resto.

Fetchers: Lectura del estado en el momento de la ejecución

Los Fetchers recuperan datos en vivo on-chain en el momento de la ejecución, no en el momento de la firma. Cuando un agente dice "intercambia todo mi saldo de WETH", el fetcher resuelve "todo mi saldo de WETH" llamando a balanceOf en el contrato de WETH justo antes de que se dispare el swap. El usuario firma una intención ("intercambia lo que tenga") y la cadena resuelve el número real cuando se ejecuta.

Constraints: Validación antes de que proceda cada llamada

Las Restricciones (Constraints) verifican los valores resueltos frente a reglas predefinidas. Una restricción puede decir: "el resultado de este swap debe ser al menos 998 USDC, o revertir". A diferencia de una verificación de salida mínima estándar integrada en una sola llamada de Uniswap, una restricción viaja con el lote y puede referenciar resultados de cualquier paso anterior.

Predicates: Condicionamiento del lote a condiciones on-chain

Los Predicados (Predicates) son verificaciones booleanas puras — entradas con target = address(0) que revierten todo el lote si su condición falla. Funcionan como barreras de seguridad entre acciones. "Solo procede con el depósito en Aave si el factor de salud (health factor) de mi bóveda se mantiene por encima de 1.5". "Solo ejecuta el reequilibrio si el oráculo de precios se ha actualizado en los últimos 60 segundos".

Cada parámetro de entrada en un lote ERC-8211 lleva tres piezas de metadatos: un tipo de fetcher que define cómo se obtiene el valor, información de enrutamiento que decide si se convierte en un objetivo de llamada, campo de valor o argumento de calldata, y predicados en línea que deben cumplirse o todo el lote se revierte.

El resultado es un único payload firmado que expresa algo como:

Intercambia todo mi saldo de WETH por USDC con un deslizamiento no superior al 0.3 %. Luego, deposita exactamente los USDC que recibí en el pool v3 de Aave, pero solo si el factor de salud de mi cuenta se mantiene por encima de 1.8. Después, verifica que el tamaño de la posición final coincida con lo que mi estrategia esperaba, o revierte todo el lote.

Esto solía requerir tres firmas separadas en una ventana de 90 segundos, o un contrato de enrutador Solidity personalizado, auditado y desplegado para un solo caso de uso. El ERC-8211 lo convierte en un único programa TypeScript que se compila en un array ComposableExecution[], se firma una vez y se ejecuta atómicamente.

Por qué esto supera a Weiroll, x402 y los SDK de proveedores

El ERC-8211 no es el primer intento de batching componible. El predecesor más cercano es Weiroll, una VM embebida que permite a los contratos expresar flujos de múltiples pasos. El equipo detrás del ERC-8211 ha sido explícito sobre la comparación: Weiroll son "scripts" — una secuencia simple de llamadas. ERC-8211 son "programas" — secuencias con controles de seguridad integrados, resolución en tiempo de ejecución y validación de restricciones que cualquier bundler puede verificar sin necesidad de confianza.

Pero la comparación más trascendental es con los stacks específicos de proveedores que se han multiplicado en los últimos 18 meses:

Marco de trabajo	Origen	Alcance	¿Es Estándar?
Coinbase x402	Coinbase, 2024	Pagos de USDC nativos de HTTP	Especificación abierta, facilitador único
Coinbase AgentKit	Coinbase, 2024	SDK completo de agentes, billetera + acciones	SDK de proveedor
ElizaOS Agent Framework	Financiado por a16z, 2024	Runtime de agentes multicadena	Código abierto, sin estándar de protocolo
Solana Agent Primitives	AI Rig Complex, ElizaOS-on-SVM	Ejecución de agentes nativos de Solana	Específico de la cadena
ERC-8211	Biconomy + Fundación Ethereum, 2026	Ejecución componible de múltiples pasos	Estándar en vía de EIP

Cada uno de estos stacks resuelve una pieza del problema de los agentes. x402 ha realizado un trabajo notable en pagos — más de 119 millones de transacciones en Base, 35 millones en Solana y aproximadamente 600 millones de dólares en volumen anualizado a marzo de 2026. AgentKit ofrece a los desarrolladores un kit integral para billeteras de agentes. ElizaOS-on-Solana ha lanzado agentes de producción reales.

Pero ninguno de ellos son estándares a nivel de protocolo. Son SDK de proveedores, rieles de pago o marcos específicos de una cadena. Un agente construido en Coinbase AgentKit no puede ejecutar trivialmente una estrategia diseñada para ElizaOS, aunque ambos funcionen sobre infraestructura adyacente a Ethereum. A medida que la población de agentes crece — y los datos de 2026 sugieren que aproximadamente 250,000 agentes on-chain activos diariamente cruzan ahora las fronteras de los proveedores de forma rutinaria — esa fragmentación se convierte en el cuello de botella.

La contribución del ERC-8211 no es "un mejor SDK". Es "una capa semántica compartida a la que cualquier SDK puede apuntar". Una vez que una cuenta inteligente habla ERC-8211, cualquier runtime de agentes — el de Biconomy, el de Coinbase, un futuro Eliza-on-EVM o algo que nadie haya construido todavía — puede enviar un payload de ejecución que la cuenta comprenda.

Cómo encaja el ERC-8211 en el stack de agentes más amplio

La Fundación Ethereum ha sido deliberada al posicionar el ERC-8211 junto a sus estándares hermanos:

• ERC-4337 (abstracción de cuentas) — el sustrato de cuentas inteligentes. Los lotes (batches) de ERC-8211 se ejecutan dentro de las cuentas ERC-4337. Las delegaciones EIP-7702, con aproximadamente 14 millones de EOAs ya registradas desde la mainnet de Pectra en mayo de 2025, también le dan al ERC-8211 un camino hacia las EOAs ordinarias.
• ERC-7579 (cuentas modulares) — la interfaz de plug-in. El ERC-8211 se implementa como un módulo, no como un fork.
• ERC-7683 (intentos cross-chain) — el estándar para expresar "Quiero este resultado en cualquier lugar". El ERC-8211 es el estándar para "ejecutar este resultado aquí".
• ERC-8004 (agentes trustless) — la capa de identidad y reputación. Un agente registrado en ERC-8004 utiliza el ERC-8211 para actuar.
• ERC-8183 (comercio entre agentes) — la primitiva de negociación. Los agentes que cierran acuerdos a través de ERC-8183 los liquidan mediante ERC-8211.

Esa estratificación es importante. Cada estándar hace una sola cosa. El ERC-8211 se encarga de la semántica de ejecución y, explícitamente, no intenta ser identidad, pagos o enrutamiento cross-chain. Esa disciplina es lo que hace probable que realmente se lance: la propuesta puede implementarse como una codificación a nivel de contrato sin ningún fork del protocolo Ethereum. Sin un hard fork, no hay un cronograma de activación de cinco años. El estándar podría ver un despliegue en producción para el tercer trimestre de 2026 si los rollups y los principales proveedores de smart wallets deciden integrarlo.

Por qué las claves de sesión de repente son importantes para los agentes

La estrella no mencionada del ERC-8211 son las claves de sesión (session keys). El estándar se compone de forma natural con wallet_grantPermissions, un método RPC de billetera que permite a un usuario aprobar, por una única vez, una delegación con límite de tiempo y alcance para un agente. El agente entonces opera dentro de esos límites sin necesidad de más avisos al usuario.

Al combinar las claves de sesión con el ERC-8211, el panorama se aclara drásticamente:

1. El usuario firma una vez: "Durante los próximos 30 días, este agente puede ejecutar swaps y depósitos en Aave en mi nombre, hasta 50,000 USDC por transacción, solo en Base y Arbitrum, y solo si mi factor de salud se mantiene por encima de 1.5".
2. El agente construye un lote ERC-8211 que respeta esas restricciones.
3. El bundler valida el lote frente al alcance de la clave de sesión antes de retransmitirlo.
4. La ejecución tiene éxito de forma atómica o se revierte de forma atómica.

Esta es la primitiva faltante que ha frenado a los agentes genuinamente autónomos. Hasta ahora, la "autonomía de los agentes" significaba confiar en las claves del agente (el modelo de Coinbase Agentic Wallet) o pedir confirmación al usuario en cada paso (el fallido flujo estilo Web2). Las claves de sesión más el ERC-8211 nos dan una tercera opción: autonomía restringida con verificación on-chain, donde el usuario define los límites y el agente opera dentro de ellos sin tener que consultar constantemente.

La implicación para la infraestructura: los proveedores de RPC se vuelven conscientes de los agentes

Aquí es donde el efecto dominó golpea la infraestructura de API y nodos. Una vez que los lotes ERC-8211 entren en producción, los proveedores de RPC ya no podrán tratar el tráfico de agentes como "tráfico de usuario regular que resulta provenir de un script". Un relayer que se comporte correctamente necesita:

• Analizar el formato del lote para identificar llamadas de fetcher, restricciones y predicados.
• Validar el alcance de la clave de sesión antes del envío, de modo que pueda rechazar lotes que excedan la autoridad delegada antes de gastar gas.
• Simular rutas de ejecución con estado en vivo, para que pueda previsualizar las razones probables de reversión.
• Mostrar fallos de predicados a los desarrolladores de agentes en un formato estructurado, no solo como cadenas de reversión (revert) de la EVM sin procesar.

Esta es una nueva superficie de producto. El RPC convencional de Ethereum fue diseñado para dApps impulsadas por humanos donde cada llamada es una acción de usuario discreta. El RPC impulsado por agentes es una carga de trabajo completamente diferente: de alta frecuencia, programática y dependiente de una simulación precisa de lotes de múltiples pasos. Los proveedores que reconozcan el cambio temprano — exponiendo endpoints conscientes de ERC-8211, paneles de control de tráfico de agentes y validación de claves de sesión como APIs de primera clase — se situarán en el centro de la economía de los agentes.

La pregunta abierta: ¿Estándar o SDK de proveedor?

El ERC-8211 lleva el nombre de la Fundación Ethereum adjunto. Eso le otorga una credibilidad que ningún SDK de proveedor puede igualar. Pero la credibilidad no es adopción. Dos resultados son plausibles.

Caso optimista: Los principales proveedores de smart wallets (Safe, Coinbase, Argent, Rabby) lanzan módulos ERC-8211 en un plazo de seis meses. La infraestructura de bundlers (Pimlico, Stackup, el propio Biconomy) añade soporte de primera clase. Los entornos de ejecución de agentes convergen en el ERC-8211 como su objetivo de ejecución. Para el cuarto trimestre de 2026, el estándar se convierte en la forma de facto en que los agentes transaccionan en la EVM, de la misma manera que el ERC-4337 se convirtió en la forma de facto en que funcionan las cuentas inteligentes.

Caso pesimista: Coinbase redobla su apuesta por AgentKit y x402 como un stack integrado verticalmente, de la misma manera que lo hizo con su Smart Wallet. Los principales protocolos DeFi lanzan integraciones de agentes específicas de proveedores en lugar de esperar al estándar. El ERC-8211 se convierte en una opción de nicho para constructores sofisticados, mientras que el flujo de agentes del mercado masivo se ejecuta a través de kits de herramientas comerciales. La fragmentación continúa.

Las señales iniciales favorecen el caso optimista. El track "Improve UX" de la Fundación Ethereum ha sido notablemente efectivo en la coordinación de proveedores de billeteras en torno a estándares compartidos; el EIP-7702 pasó de propuesta a 14 millones de autorizaciones en menos de un año. El ERC-8211 tiene los mismos ingredientes estructurales: problema claro, solución limpia, sin necesidad de fork del protocolo y utilidad inmediata para los desarrolladores que ya están lanzando agentes.

Qué observar a continuación

Los próximos 90 días revelarán si el ERC-8211 está destinado a ser el estándar por defecto o simplemente otra propuesta con buenas intenciones. Tres señales son las que más importan:

1. Plazos de integración de billeteras. Si Safe y Coinbase Smart Wallet lanzan módulos ERC-8211 para el tercer trimestre (Q3), la adopción estará en marcha.
2. Economía de los bundlers. Los lotes de ERC-8211 son más costosos de simular que los lotes estáticos. Los modelos de tarifas por parte de los bundlers deberán evolucionar.
3. Ecosistema de auditoría. La ejecución compuesta introduce nuevas superficies de ataque — manipulación del fetcher, omisión de restricciones, ordenamiento de predicados. Los primeros informes de auditoría importantes sobre implementaciones de ERC-8211 en producción establecerán la línea base de seguridad para toda la economía de agentes.

Para los desarrolladores que deciden dónde invertir en 2026, la respuesta estratégica es cada vez más clara: construir basándose en estándares, no en SDKs de proveedores. El ERC-8211 es la señal más fuerte hasta ahora de que la infraestructura de agentes de Ethereum será una estructura de capas de estándares públicos, no un jardín vallado de kits propietarios. Los 250,000 agentes que transaccionan diariamente hoy serán 25 millones para 2028 si las tendencias actuales se mantienen, y las vías sobre las que operan se parecerán mucho más al ERC-8211 que a la interfaz de producto de cualquier empresa individual.

La capa de ejecución para agentes autónomos on-chain tiene un nombre. Solo hizo falta la Fundación Ethereum y un pequeño equipo en Bangalore para dárselo.

---

BlockEden.xyz proporciona infraestructura de RPC de grado de producción, indexación y abstracción de cuentas para desarrolladores que despliegan agentes de IA en Ethereum, Base, Arbitrum y otras cadenas EVM. A medida que el ERC-8211 y el stack de agentes más amplio maduran, nuestros endpoints están diseñados para manejar las cargas de trabajo de alta frecuencia y uso intensivo de simulación que demandan los agentes autónomos. Explore nuestro mercado de APIs para comenzar a construir sobre una infraestructura diseñada para la economía de agentes.