ERC-8211 Smart Batching: Como a Biconomy e a Ethereum Foundation Acabaram de Reescrever as Regras para Agentes de IA On-Chain

Em 7 de abril de 2026, a Biconomy e a Ethereum Foundation publicaram silenciosamente uma proposta que pode vir a ser o padrão de infraestrutura de agentes mais consequente desde o ERC-4337. Chama-se ERC-8211 e, superficialmente, parece uma atualização de contabilidade: uma nova forma de codificar transações em lote (batch transactions). Olhando mais de perto, é algo muito maior — a primeira resposta a nível de protocolo para uma pergunta que assombra a IA on-chain há dois anos: como um agente autônomo transaciona de fato com segurança na Ethereum sem que o usuário assine cada movimento individual?

O momento não é acidental. Com aproximadamente 62 milhões de contas inteligentes (smart accounts) agora ativas em cadeias EVM, 2,4 bilhões de UserOperations cumulativas processadas e uma população em rápido crescimento de agentes autônomos executando estratégias reais de DeFi em nome dos usuários, a Ethereum atingiu o limite do que as transações estáticas em lote podem expressar. O ERC-8211 — apelidado de "smart batching" (batching inteligente) — é o padrão projetado para quebrar esse teto.

O Problema que o Batching Estático Não Conseguiu Resolver

Nos últimos dois anos, o ERC-4337 e o EIP-5792 fizeram o trabalho pesado para transações em lote. Eles permitem que uma conta inteligente agrupe várias chamadas sob uma única assinatura: aprovar um token, trocá-lo no Uniswap, depositar os rendimentos no Aave, tudo de forma atômica. Esse modelo funciona perfeitamente — até você lembrar que o DeFi é um alvo móvel.

Fluxos reais de DeFi produzem resultados dinâmicos e imprevisíveis. Uma troca (swap) pode retornar 1.000 USDC ou 998 USDC, dependendo do slippage. Uma retirada de um cofre (vault) pode render o principal mais 23,4 dólares de juros acumulados, ou 23,7. O batching estático força desenvolvedores e agentes a duas opções ruins:

• Codificar valores otimistas de forma rígida (hardcode) — e ver todo o lote ser revertido quando a realidade fica abaixo do esperado.
• Subestimar de forma conservadora — e deixar valor retido em etapas intermediárias que a próxima chamada não consegue alcançar.

De qualquer forma, o usuário paga o custo: transações falhas, capital bloqueado ou rendimentos abaixo do ideal. Para um agente de IA operando sem supervisão, isso é pior do que ineficiente. É operacionalmente insustentável. Um agente que precisa acordar o usuário toda vez que um swap retorna um valor inesperado não é um agente — é um Slackbot com uma carteira.

O ERC-8211 resolve isso introduzindo três primitivas que transformam um lote de uma "receita congelada" em um "programa com verificações de segurança incorporadas".

Os Três Pilares: Fetchers, Constraints e Predicates

A genialidade do ERC-8211 está em sua compacidade. Ele não tenta ser uma máquina virtual. Ele adiciona exatamente três coisas ao formato de lote existente e deixa o resto da infraestrutura — bundlers ERC-4337, autorizações EIP-7702, contas modulares ERC-7579 — lidar com os detalhes técnicos.

Fetchers: Ler o estado no momento da execução

Os Fetchers recuperam dados on-chain em tempo real no momento da execução, e não no momento da assinatura. Quando um agente diz "troque todo o meu saldo de WETH", o fetcher resolve "todo o saldo de WETH" chamando balanceOf no contrato WETH logo antes do swap ocorrer. O usuário assina uma intenção ("troque o que eu tiver"), e a rede resolve o número real no momento da execução.

Constraints: Validar antes que cada chamada prossiga

As Constraints (Restrições) verificam os valores resolvidos em relação a regras predefinidas. Uma restrição pode dizer: "o resultado deste swap deve ser de pelo menos 998 USDC, ou reverta". Ao contrário de uma verificação de saída mínima comum integrada em uma única chamada do Uniswap, uma constraint viaja com o lote e pode referenciar saídas de qualquer etapa anterior.

Predicates: Condicionar o lote a condições on-chain

Os Predicates (Predicados) são puras verificações booleanas — entradas com target = address(0) que revertem todo o lote se sua condição falhar. Eles funcionam como trilhos de segurança entre as ações. "Só prossiga com o depósito no Aave se o fator de saúde do meu cofre permanecer acima de 1,5". "Só execute o rebalanceamento se o oráculo de preço tiver sido atualizado nos últimos 60 segundos".

Cada parâmetro de entrada em um lote ERC-8211 carrega três metadados: um tipo de fetcher que define como o valor é obtido, informações de roteamento que decidem se ele se torna um alvo de chamada, campo de valor ou argumento de calldata, e predicados em linha que devem ser válidos ou todo o lote é revertido.

O resultado é um único payload assinado que expressa algo como:

Troque todo o meu saldo de WETH por USDC com um slippage não superior a 0,3%. Em seguida, deposite exatamente o USDC que recebi na pool v3 do Aave, mas apenas se o fator de saúde da minha conta permanecer acima de 1,8. Por fim, verifique se o tamanho da posição final corresponde ao que minha estratégia esperava, ou reverta todo o lote.

Isso costumava exigir três assinaturas separadas em uma janela de 90 segundos, ou um contrato de roteador Solidity personalizado, auditado e implantado para um único caso de uso. O ERC-8211 transforma isso em um único programa TypeScript que compila para um array ComposableExecution[], assina uma vez e executa atomicamente.

Por que isso supera o Weiroll, x402 e os SDKs de Fornecedores

O ERC-8211 não é a primeira tentativa de batching compostável. O predecessor mais próximo é o Weiroll, uma VM incorporada que permite que contratos expressem fluxos de várias etapas. A equipe por trás do ERC-8211 tem sido explícita sobre a comparação: Weiroll são "scripts" — uma sequência simples de chamadas. O ERC-8211 são "programas" — sequências com verificações de segurança integradas, resolução em tempo de execução e validação de restrições que qualquer bundler pode verificar sem confiança.

Mas a comparação mais consequente é com as pilhas específicas de fornecedores que se multiplicaram nos últimos 18 meses:

Framework	Origem	Escopo	Padrão?
Coinbase x402	Coinbase, 2024	Pagamentos USDC nativos em HTTP	Especificação aberta, facilitador único
Coinbase AgentKit	Coinbase, 2024	SDK completo para agentes, carteira + ações	SDK de fornecedor
ElizaOS Agent Framework	Financiado por a16z, 2024	Runtime de agente multi-chain	Código aberto, sem padrão de protocolo
Solana Agent Primitives	AI Rig Complex, ElizaOS-on-SVM	Execução de agentes nativa da Solana	Específico da rede
ERC-8211	Biconomy + Ethereum Foundation, 2026	Execução compostável de várias etapas	Padrão em trilha de EIP

Cada uma dessas pilhas resolve uma parte do problema dos agentes. O x402 fez um trabalho notável em pagamentos — mais de 119 milhões de transações na Base, 35 milhões na Solana e aproximadamente US$ 600 milhões em volume anualizado até março de 2026. O AgentKit oferece aos desenvolvedores um kit completo para carteiras de agentes. O ElizaOS-on-Solana entregou agentes de produção reais.

Mas nenhum deles é um padrão a nível de protocolo. Eles são SDKs de fornecedores, canais de pagamento ou frameworks específicos de cada rede. Um agente construído no Coinbase AgentKit não pode executar trivialmente uma estratégia projetada para o ElizaOS, mesmo que ambos rodem em infraestrutura adjacente à Ethereum. À medida que a população de agentes aumenta — e os dados de 2026 sugerem cerca de 250.000 agentes on-chain ativos diariamente cruzando fronteiras de fornecedores rotineiramente — essa fragmentação torna-se o gargalo.

A contribuição do ERC-8211 não é "um SDK melhor". É "uma camada semântica compartilhada que qualquer SDK pode visar". Uma vez que uma conta inteligente suporte o ERC-8211, qualquer runtime de agente — o da Biconomy, o da Coinbase, um futuro Eliza-on-EVM ou algo que ninguém construiu ainda — pode enviar um payload de execução que a conta entenda.

Como o ERC-8211 se Encaixa na Pilha Mais Ampla de Agentes

A Fundação Ethereum tem sido deliberada ao posicionar o ERC-8211 ao lado de seus "irmãos":

• ERC-4337 (abstração de conta) — o substrato de conta inteligente. Os lotes (batches) do ERC-8211 são executados dentro de contas ERC-4337. As delegações do EIP-7702, com cerca de 14 milhões de EOAs já registradas desde a mainnet Pectra em maio de 2025, dão ao ERC-8211 um caminho também para as EOAs comuns.
• ERC-7579 (contas modulares) — a interface de plug-in. O ERC-8211 é implementado como um módulo, não como um fork.
• ERC-7683 (intenções cross-chain) — o padrão para expressar "Eu quero este resultado em qualquer lugar". O ERC-8211 é o padrão para "execute este resultado aqui".
• ERC-8004 (agentes trustless) — a camada de identidade e reputação. Um agente registrado no ERC-8004 usa o ERC-8211 para agir.
• ERC-8183 (comércio agente-a-agente) — a primitiva de negociação. Agentes que fecham negócios via ERC-8183 os liquidam via ERC-8211.

Essa estratificação é importante. Cada padrão faz uma coisa. O ERC-8211 cuida da semântica de execução e, explicitamente, não tenta ser identidade, pagamentos ou roteamento cross-chain. Essa disciplina é o que torna provável que ele seja realmente lançado: a proposta pode ser implementada como uma codificação em camada de contrato sem qualquer fork no protocolo Ethereum. Sem hard fork, não há um cronograma de ativação de cinco anos. O padrão poderá ver a implantação em produção até o terceiro trimestre de 2026, caso os rollups e os principais fornecedores de carteiras inteligentes decidam integrá-lo.

Por que as Chaves de Sessão Subitamente Importam para Agentes

A estrela tácita do ERC-8211 são as chaves de sessão. O padrão se compõe naturalmente com o wallet_grantPermissions — um método RPC de carteira que permite ao usuário aprovar, uma única vez, uma delegação com limite de tempo e escopo para um agente. O agente então opera dentro desses limites sem solicitações adicionais ao usuário.

Combine chaves de sessão com ERC-8211 e o cenário torna-se drasticamente mais claro:

1. O usuário assina uma vez: "Pelos próximos 30 dias, este agente pode executar trocas (swaps) e depósitos no Aave em meu nome, até 50.000 USDC por transação, apenas na Base e Arbitrum, e somente se meu fator de saúde permanecer acima de 1.5."
2. O agente constrói um lote ERC-8211 que respeita essas restrições.
3. O bundler valida o lote em relação ao escopo da chave de sessão antes de retransmitir.
4. A execução ocorre atomicamente com sucesso ou reverte atomicamente.

Esta é a primitiva que faltava e que impedia o surgimento de agentes genuinamente autônomos. Até agora, "autonomia de agente" significava ou confiar nas chaves do agente (modelo da Coinbase Agentic Wallet) ou solicitar a confirmação do usuário em cada etapa (o fluxo falho no estilo Web2). Chaves de sessão somadas ao ERC-8211 nos dão uma terceira opção: autonomia restrita com verificação on-chain, onde o usuário define os limites e o agente opera dentro deles sem precisar "ligar para casa".

A Implicação na Infraestrutura: Provedores de RPC Tornam-se Cientes de Agentes

É aqui que o efeito cascata atinge a infraestrutura de API e de nós. Uma vez que os lotes ERC-8211 entrem em produção, os provedores de RPC não poderão mais tratar o tráfego de agentes como "tráfego de usuário regular que por acaso vem de um script". Um relayer com comportamento correto precisa:

• Analisar o formato do lote para identificar chamadas de busca (fetcher), restrições e predicados.
• Validar o escopo da chave de sessão antes do envio, para que possa rejeitar lotes que excedam a autoridade delegada antes de gastar gas.
• Simular caminhos de execução com estado em tempo real, para que possa prever prováveis motivos de reversão.
• Expor falhas de predicados para desenvolvedores de agentes em um formato estruturado, e não apenas como strings de reversão brutas da EVM.

Esta é uma nova superfície de produto. O RPC convencional do Ethereum foi projetado para dApps conduzidos por humanos, onde cada chamada é uma ação discreta do usuário. O RPC focado em agentes é uma carga de trabalho inteiramente diferente: alta frequência, programática e dependente da simulação precisa de lotes de várias etapas. Os provedores que reconhecerem essa mudança cedo — expondo endpoints compatíveis com ERC-8211, painéis de tráfego de agentes e validação de chaves de sessão como APIs de primeira classe — estarão no centro da economia de agentes.

A Questão em Aberto: Padrão ou SDK de Fornecedor?

O ERC-8211 tem o nome da Fundação Ethereum associado. Isso lhe confere uma credibilidade que nenhum SDK de fornecedor pode igualar. Mas credibilidade não é adoção. Dois resultados são plausíveis.

Caso otimista: Os principais fornecedores de carteiras inteligentes (Safe, Coinbase, Argent, Rabby) lançam módulos ERC-8211 em seis meses. A infraestrutura de bundlers (Pimlico, Stackup, a própria Biconomy) adiciona suporte de primeira classe. Os ambientes de execução de agentes convergem para o ERC-8211 como seu alvo de execução. Até o quarto trimestre de 2026, o padrão torna-se a forma de facto para agentes transacionarem na EVM, assim como o ERC-4337 se tornou a forma de facto de funcionamento das contas inteligentes.

Caso pessimista: A Coinbase aposta dobrado no AgentKit e no x402 como uma pilha integrada verticalmente, da mesma forma que fez com a Smart Wallet. Os principais protocolos DeFi lançam integrações de agentes específicas de fornecedores em vez de esperar pelo padrão. O ERC-8211 torna-se uma escolha de nicho para construtores sofisticados, enquanto o fluxo de agentes para o mercado de massa passa por kits de ferramentas comerciais. A fragmentação continua.

Os sinais iniciais favorecem o caso otimista. A trilha "Improve UX" da Fundação Ethereum tem sido notavelmente eficaz na coordenação de fornecedores de carteiras em torno de padrões compartilhados — o EIP-7702 passou de proposta a 14 milhões de autorizações em menos de um ano. O ERC-8211 possui os mesmos ingredientes estruturais: problema claro, solução limpa, sem necessidade de fork no protocolo e utilidade imediata para construtores que já estão lançando agentes.

O que acompanhar a seguir

Os próximos 90 dias revelarão se o ERC-8211 está destinado a ser o padrão ou apenas mais uma proposta bem-intencionada. Três sinais são os que mais importam:

1. Cronogramas de integração de carteiras. Se a Safe e a Coinbase Smart Wallet lançarem módulos ERC-8211 até o terceiro trimestre (Q3), a adoção estará no caminho certo.
2. Economia de bundlers. Lotes ERC-8211 são mais caros para simular do que lotes estáticos. Os modelos de taxas do lado do bundler precisarão evoluir.
3. Ecossistema de auditoria. A execução composta introduz novas superfícies de ataque — manipulação de fetcher, contorno de restrições (constraint bypass), ordenação de predicados. Os primeiros grandes relatórios de auditoria sobre implantações de produção do ERC-8211 estabelecerão a base de segurança para toda a economia de agentes.

Para os desenvolvedores que estão decidindo onde investir em 2026, a resposta estratégica é cada vez mais clara: construa para padrões, não para SDKs de fornecedores. O ERC-8211 é o sinal mais forte até agora de que a infraestrutura de agentes do Ethereum será um bolo em camadas de padrões públicos, e não um jardim murado de kits proprietários. Os 250.000 agentes que transacionam diariamente hoje serão 25 milhões até 2028, se as tendências atuais se mantiverem, e os trilhos em que eles operam se parecerão muito mais com o ERC-8211 do que com a superfície de produto de qualquer empresa individual.

A camada de execução para agentes autônomos on-chain tem um nome. Foi preciso apenas a Ethereum Foundation e uma pequena equipe em Bangalore para dar um a ela.

---

BlockEden.xyz fornece infraestrutura de RPC, indexação e abstração de conta de nível de produção para desenvolvedores que implantam agentes de IA no Ethereum, Base, Arbitrum e outras cadeias EVM. À medida que o ERC-8211 e a pilha de agentes mais ampla amadurecem, nossos endpoints são projetados para lidar com as cargas de trabalho de alta frequência e pesadas em simulação que os agentes autônomos exigem. Explore nosso marketplace de APIs para começar a construir em uma infraestrutura projetada para a economia de agentes.