ERC-8211 visa permitir execução dinâmica para agentes de IA no DeFi

A partir de 2025, muitas pessoas podem gradualmente se acostumar a um novo modo de interação: dizer a um GPT ou Gemini “me ajude a planejar minha viagem a Hong Kong na próxima semana e recomende voos e hotéis adequados”, e ele realizará silenciosamente atrás dos bastidores uma série de etapas — como pesquisa de informações, filtragem de critérios, seleção de rotas e comparação de preços —, entregando apenas os resultados para você confirmar.

Mas, trazer as mesmas expectativas para a cadeia, a história muda completamente.

Por exemplo, se você der um comando a um Agente DeFi: “Troque todos os ETH da sua carteira por USDC, transfira-os para a cadeia Base e depósito integralmente na Aave”. Objetivamente, do ponto de vista de “compreender a necessidade” e “planejar o caminho”, os agentes de hoje talvez consigam fazer isso; a verdadeira lacuna ocorre na fase de execução:

Você ainda provavelmente precisará concluir passo a passo as operações de assinatura, autorização, troca, transferência entre cadeias e depósito, e cada etapa está exposta aos riscos de variação de slippage, flutuação de gas, atrasos na ponte e mudanças de estado na cadeia, o que significa que, se qualquer etapa intermediária divergir do esperado, as ações anteriores podem não ser revertidas e as subsequentes podem não ser conectadas, resultando, no final, em um processo incompleto e parcialmente deixado na cadeia.

O problema não é que a IA não seja suficientemente inteligente, mas sim que a camada de execução na cadeia ainda carece de uma forma verdadeiramente adaptada para Agentes.

Por essa razão, no início de abril de 2026, a Biconomy, em parceria com a Ethereum Foundation, lançou a ERC-8211, destinada a resolver o problema das "restrições estáticas" na execução de contratos inteligentes atuais, oferecendo um nível de execução mais expressivo para agentes de IA e fluxos de trabalho DeFi complexos, tentando preencher esse quebra-cabeça ausente.

Nos últimos um a dois anos, o foco da indústria de criptomoedas está claramente se deslocando de escalabilidade L2 e liquidez RWA para o tema altamente disruptivo de como os agentes de IA realmente assumirão operações on-chain.

Objetivamente, recentemente também vimos muitas práticas, desde "emitir estratégias DeFi de múltiplos passos por meio de linguagem natural" até "permitir que agentes autônomos gerenciem uma carteira inteira de investimentos entre cadeias", e a maioria dessas ideias já está madura no nível de demonstração, seja na geração de estratégias DeFi de múltiplos passos por linguagem natural, execução autônoma de reequilíbrio, migração automática de rendimentos, ajuste de posições entre cadeias ou até gestão de carteiras mais complexas.

Do ponto de vista de raciocínio e orquestração, a capacidade da IA já avançou bastante, mas quando realmente colocada em um ambiente de produção, as deficiências na camada de execução tornam-se cada vez mais evidentes.

Quando se trata de um ambiente de produção, essa limitação pode ser resumida em uma frase: DeFi é dinâmico, mas a maioria dos batchs de hoje ainda é estática.

O site oficial e o tópico de discussão do ERC-8211 esclarecem muito bem esse problema: o ERC-4337 e o EIP-5792 atuais já avançaram do modelo antigo de “uma assinatura para uma chamada” para a nova fase em que “uma assinatura pode empacotar múltiplas chamadas”, mas os parâmetros dessas chamadas ainda são, essencialmente, congelados no momento da assinatura.

Ou seja, os valores inseridos pelo usuário durante a assinatura — o montante, o valor-alvo e a saída esperada — não serão ajustados automaticamente quando executados, mesmo que o estado da cadeia tenha mudado.

O DeFi em si é exatamente cheio de incertezas. A saída real de uma Swap depende do slippage e da liquidez dentro do bloco executado; o tempo de chegada e o valor final recebido em uma Bridge dependem do mecanismo e das taxas da própria ponte; a proporção share-to-asset de protocolos de empréstimo ou Vault também está em constante mudança.

After all, the value seen by the user or Agent at the time of signing is often just a current estimate, not the actual result at execution.

Para entender o que o ERC-8211 resolve, primeiro veja um exemplo mais típico: suponha que um Agente queira fazer algo que parece muito comum — trocar o ETH da conta por USDC e depositar integralmente no Spark para ganhar juros.

No modelo atual de processamento em lote estático, o Agente precisa estimar antecipadamente quantos USDC receberá após o Swap, forçando-o a definir previamente o valor de entrada para a segunda etapa ao assinar. Se a estimativa for muito alta, o valor real recebido pode ser insuficiente, fazendo com que todo o lote seja revertido; se for muito baixa, parte dos fundos permanece ociosa na carteira, sem ser utilizada.

Em outras palavras, entra-se basicamente na chamada situação de dilema: ou se assume o risco de falha, ou se incorre no custo de oportunidade. É por isso que muitos processos on-chain que parecem não ser tão complexos tornam-se rapidamente frágeis quando os passos se estendem a 5, 8 ou mais etapas, ou cruzam duas cadeias — não porque a estratégia em si seja complexa demais para ser descrita, mas porque o modelo de execução atual depende excessivamente de parâmetros pré-definidos.

Em resumo, o limite de capacidade do batch estático determina, na verdade, o limite superior das estratégias que o Agente pode executar com segurança.

Do ponto de vista deste ângulo, o que o ERC-8211 busca resolver não é como os Agentes de IA tomam decisões, mas sim se há, na cadeia, uma maneira mais natural, estável e segura de executá-las após a decisão já ter sido tomada. Assim, a execução na cadeia ganha, pela primeira vez, uma forma de expressão nativamente projetada para Agentes de IA.

A inovação central do ERC-8211 não está em encaixar mais etapas em uma única assinatura, mas em elevar o processamento em lote de uma sequência de transações com parâmetros fixos para um "programa cujos parâmetros são avaliados dinamicamente durante a execução".

Parece realmente abstrato, mas não é difícil de entender; a equipe oficial descreveu com uma frase: From transactions to programs.

Isso significa que o ERC-8211 não mais considera o batch como uma lista de ações executadas sequencialmente, mas sim como um programa de execução avaliado em tempo de execução, com condições de segurança; mais detalhadamente, ele implementa isso por meio de três primitivas combináveis:

• Fetchers (getters): Definem de onde esse parâmetro obtém seu valor; pode ser uma consulta ao saldo atual de um endereço, fazendo com que o parâmetro não seja mais uma captura no momento da assinatura, mas sim uma leitura em tempo real obtida do estado da cadeia no momento da execução;
• Constraints: Após os parâmetros serem extraídos, ainda devem passar por verificação de restrições embutidas — por exemplo, «o USDC recebido deve ser ≥ 2500» ou «o slippage não pode exceder 0,5%» — essas restrições são validadas antes que os valores sejam encaminhados para a próxima chamada; se qualquer uma falhar, todo o lote é imediatamente revertido;
• Predicados (condições de gatilho): Podem ser entendidos como guardiões entre etapas, não responsáveis por gerar valores, mas por determinar se a execução deve continuar. Por exemplo, em cenários de ponte entre cadeias, o batch do lado Ethereum pode permanecer bloqueado pelo predicado até que a condição “WETH transferido da outra cadeia já foi recebido” seja atendida, não enviando a transação até então.

Neste conjunto de design, cada parâmetro deve responder a duas perguntas: primeiro, de onde esse valor deve vir durante a execução; segundo, quais condições devem ser atendidas antes que ele seja realmente utilizado na chamada. Assim, combinados, esses três elementos transformam um lote não apenas em uma sequência de transações, mas em um programa com verificações de segurança embutidas.

No final das contas, o modelo mental do processamento em batch estático é uma lista — executar passos A, B e C em sequência; já o modelo mental do ERC-8211 é um programa condicional — após A ser executado, use a saída real de A como entrada para B; B só avança para C se atender às restrições; se qualquer etapa não atingir o esperado, todo o lote é revertido.

Na verdade, podemos entendê-lo simplesmente como um mecanismo de "lote inteligente" projetado especificamente para AI Agents e operações complexas de DeFi, pois, nas operações tradicionais na cadeia, concluir uma estratégia complexa de DeFi geralmente exige várias transações independentes: retirar fundos de um protocolo de empréstimo, trocar tokens e depositá-los novamente em outro protocolo (leitura complementar: Visão Geral dos Protocolos de IA Cripto: Como Construir um Novo Sistema Operacional para AI Agents a Partir do Campo de Batalha Principal da Ethereum?).

Cada etapa exige assinatura e confirmação separadas, o que já é complicado para usuários humanos e se torna um gargalo para agentes de IA que precisam de operações autônomas em alta frequência. A solução do ERC-8211 permite combinar várias operações de blockchain em uma única transação, resolvendo dinamicamente os valores reais durante a execução de cada etapa e exigindo que condições pré-definidas sejam atendidas antes de prosseguir para a próxima.

Por exemplo, um agente pode realizar isso em uma única transação assinada: retirar fundos do Aave → trocar o valor recebido no Uniswap → depositar o resultado na Compound — tudo executado atomicamente, sem a necessidade de escrever um novo contrato inteligente.

O ERC-8211 merece atenção da indústria de carteiras não apenas porque é adequado para Agentes, mas também porque redefinirá o papel das carteiras na cadeia de interação.

Nos wallets anteriores, era mais como um assinador seguro, cuja função era armazenar chaves privadas, exibir transações, permitir que o usuário confirmasse e depois enviar a assinatura. Esse papel era suficientemente importante na era EOA e continua válido na era da abstração de conta; no entanto, se, no futuro, um número cada vez maior de operações na cadeia for realizada por Agentes, o papel do wallet se tornará ainda mais central e oneroso.

A razão é simples: quando os usuários deixam de manipular manualmente cada ação na cadeia e passam a autorizar um Agente para executar um conjunto completo de objetivos, a carteira precisa ter capacidade para lidar com esse tipo de interação de nível superior, exibindo não apenas um endereço de contrato e um trecho de calldata, mas todo um programa de execução de “intenção – lógica de valorização – julgamento condicional – resultado final”.

Portanto, o que os carteiras do futuro precisarão entender não será apenas transações, mas programas. O ERC-8211 fornece, nesse nível, um ponto de contato mais claro para as carteiras, pois essas semânticas de execução são explicitamente incorporadas na estrutura de codificação — de onde vêm os parâmetros, quais condições devem ser atendidas, quando prosseguir e quando reverter — tudo isso não é mais uma caixa preta oculta na lógica de backend, mas sim um objeto que pode ser interpretado, simulado e exibido pela carteira.

Do ponto de vista da carteira, todo esse mecanismo aponta finalmente para a mesma coisa: o usuário não está mais assinando uma série de chamadas subjacentes que dificilmente consegue compreender por completo, mas sim um programa de execução orientado por resultados, com limites claros e condições verificáveis:

• O Agente de IA pode ser responsável por entender a intenção do usuário e gerar caminhos;
• A carteira é responsável por exibir este caminho de forma mais clara para o usuário revisar;
• E o relayer é responsável apenas por enviar quando as condições forem atendidas, sem permissão para alterar os resultados;

É exatamente por isso que a execução não custodial é considerada um pré-requisito para o Agentic DeFi, pois os agentes podem participar, mas a soberania, as restrições e o encerramento final permanecem na cadeia — e é aí que o ERC-8211 se encaixa perfeitamente com carteiras inteligentes, pois incorpora a "expressão segura de intenções complexas" diretamente no padrão do protocolo.

É importante notar que o ERC-8211 é totalmente compatível com frameworks de abstração de conta, como ERC-4337, EIP-7702 e ERC-7579; ele não substitui a abstração de conta, mas adiciona uma camada adicional de semântica de execução programática para Agentes.

Se ERC-4337 resolve "quem pode representar-me para iniciar uma transação" e EIP-7702 resolve "como um EOA pode temporariamente adquirir capacidades de contrato inteligente", então ERC-8211 resolve se, uma vez que o Agente comece a operar em meu nome, ele pode concluir toda uma cadeia de decisões em uma única assinatura.

Revendo a evolução dos padrões de interação na cadeia do Ethereum nos últimos 10 anos:

• Fase um: Uma assinatura = uma chamada de função (era EOA)
• Fase dois: Uma assinatura = um conjunto de chamadas empacotadas estáticas (era ERC-4337, EIP-5792)
• Fase três: Uma assinatura = um programa de intenção com avaliação dinâmica (era ERC-8211)

Cada salto significa que o usuário (ou o agente que o representa) pode expressar metas mais complexas com menos atrito.

Embora o ERC-8211 ainda esteja em fase de rascunho e as discussões técnicas estejam em andamento, a adoção em larga escala do protocolo ainda exigirá tempo, sua direção já é suficientemente clara: quando os AI Agents começarem verdadeiramente a tomar decisões on-chain em nome das pessoas, a blockchain precisará de uma sintaxe nativa e correspondente para execução.