Quando carteiras começam a incorporar agentes de IA: por que o novo paradigma de interação ERC-8211 merece atenção?

A partir de 2025, muitas pessoas talvez comecem a se acostumar com uma nova forma de interação: dizer ao GPT ou Gemini uma frase como “Me ajude a planejar a viagem para Hong Kong na próxima semana e recomende passagens aéreas e hotéis adequados”, e ele irá silenciosamente realizar buscas de informações, filtragem de condições, escolha de rotas, comparação de preços e uma série de etapas, entregando apenas o resultado para sua confirmação.

No entanto, levar a mesma expectativa para a cadeia, a história muda completamente.

Por exemplo, você dá uma instrução a um Agente DeFi: “Troque ETH na carteira por USDC, atravesse para a cadeia Base, e deposite o valor total na Aave”, objetivamente, do ponto de vista de “entender a necessidade” e “planejar o caminho”, o Agente de hoje talvez não seja incapaz de fazer isso, mas a verdadeira lacuna aparece na etapa de execução:

Você ainda provavelmente precisará completar etapas de assinatura, autorização, troca, cross-chain e depósito, uma a uma, e cada passo fica exposto ao risco de variações de slippage, oscilações de Gas, atrasos na ponte e mudanças no estado na cadeia, o que significa que, se uma etapa divergir do esperado, as ações anteriores podem não ser revertidas, e as seguintes podem não se encaixar, deixando na cadeia muitas vezes apenas um fluxo incompleto e semiacabado.

O problema não está na inteligência artificial ser pouco inteligente, mas na camada de execução na cadeia ainda faltar uma forma realmente adequada de expressar ações para um Agente.

Por isso mesmo, em abril de 2026, a Biconomy e a Ethereum Foundation lançaram conjuntamente o ERC-8211, com o objetivo de resolver o problema das “limitações estáticas” na execução de contratos inteligentes atuais, oferecendo uma camada de execução mais expressiva para agentes de IA e fluxos complexos de DeFi, tentando preencher essa peça que falta.

I. A “última lacuna” na integração de Agentes de IA na cadeia

Nos últimos um ou dois anos, o foco da indústria de criptomoedas tem se deslocado de escalabilidade de L2, liquidez de RWA, para a questão disruptiva de como os Agentes de IA podem realmente assumir operações na cadeia.

Objetivamente, de “usar linguagem natural para emitir estratégias multi-step de DeFi” a “deixar um Agente autônomo gerenciar um portfólio de investimentos cross-chain”, temos visto várias implementações na prática, e a maioria dessas ideias já amadureceu em demonstrações, incluindo geração de estratégias DeFi em múltiplos passos, execução autônoma de reequilíbrios, migração automática de rendimentos, ajustes de posições cross-chain, e até gerenciamento de portfólios mais complexos.

Do ponto de vista de raciocínio e orquestração, a capacidade da IA já avançou bastante, mas quando realmente a colocamos em produção, as limitações na camada de execução ficam cada vez mais evidentes.

Na prática, essa limitação pode ser resumida assim: DeFi é dinâmico, mas a maioria dos batchs (processamentos em lote) atuais ainda são estáticos.

O site e os debates do ERC-8211 deixam isso claro: embora o ERC-4337 e o EIP-5792 tenham levado o antigo modelo de “uma assinatura para uma chamada” para um novo estágio de “uma assinatura que pode agrupar múltiplas chamadas”, os parâmetros dessas chamadas ainda permanecem, em essência, congelados no momento da assinatura.

Ou seja, os valores, metas e resultados esperados que o usuário insere na assinatura não se ajustam automaticamente às mudanças de estado na cadeia durante a execução.

Por sua própria natureza, DeFi é cheio de incertezas. O resultado de uma troca (swap) depende do slippage e da liquidez naquele bloco; o tempo de chegada e o valor final de uma ponte (bridge) dependem do mecanismo e das taxas da ponte; a proporção de share-to-asset em protocolos de empréstimo ou Vaults também está em constante mudança.

No final, os valores que o usuário ou o Agente vê na assinatura muitas vezes são apenas estimativas momentâneas, não os resultados reais durante a execução.

Para entender o que o ERC-8211 resolve, considere um exemplo clássico: suponha que um Agente queira fazer algo aparentemente simples — trocar ETH na conta por USDC, e depositar o valor total na Spark para ganhar juros.

No modelo de processamento em batch estático atual, o Agente precisa estimar antes da assinatura quanto USDC receberá após a troca, o que muitas vezes força a fixar antecipadamente o valor de entrada na segunda etapa, levando a um cenário em que, se a estimativa for alta demais, o valor real recebido não for suficiente, causando uma reversão do lote; ou, se for baixa demais, deixa parte do capital ocioso na carteira sem uso.

Em outras palavras, ele entra numa espécie de dilema: assumir o risco de falha ou o custo de oportunidade. Por isso, muitas operações na cadeia, que parecem simples, se tornam frágeis ao serem estendidas a 5, 8 passos ou cruzando duas cadeias — não porque a estratégia seja complexa demais para descrever, mas porque o paradigma de execução atual depende demais de parâmetros fixos.

Resumindo, a capacidade máxima do processamento em batch estático limita o que o Agente pode executar de forma segura.

Dessa forma, o ERC-8211 não busca resolver como o IA toma decisões, mas sim, após a decisão estar tomada, se há uma forma mais natural, estável e segura de executá-la na cadeia. Assim, a execução na cadeia passa a ter uma expressão nativa, pensada para Agentes de IA.

II. O que exatamente o ERC-8211 mudou?

A inovação central do ERC-8211 não está em colocar mais passos em uma única assinatura, mas em transformar o processamento em batch de uma sequência de transações com parâmetros fixos em um “programa de avaliação dinâmica em tempo de execução”.

Parece abstrato, mas a descrição oficial é simples: “De transações a programas”.

Isso significa que o ERC-8211 não trata o batch como uma lista de ações a serem executadas em sequência, mas como um programa de execução que avalia seus parâmetros em tempo de execução, com condições de segurança. Especificamente, ele realiza isso por meio de três primitivas combináveis:

• Fetchers (buscadores): definem de onde obter o valor de um parâmetro, podendo ser uma consulta ao saldo atual de um endereço, por exemplo, tornando o valor não uma captura instantânea na assinatura, mas uma leitura em tempo real do estado na cadeia durante a execução;
• Constraints (restrições): após obter o valor, ele passa por verificações inline — por exemplo, “USDC recebido deve ser pelo menos 2500”, ou “slippage não pode ultrapassar 0,5%”. Essas restrições são verificadas antes de passar para a próxima chamada, e qualquer falha faz o lote inteiro reverter;
• Predicates (predicados): atuam como guardiões entre etapas, não gerando valores, mas decidindo se a execução deve continuar. Por exemplo, em um cenário cross-chain, o batch na Ethereum pode depender do predicate “WETH recebido na ponte já chegou”, e só prosseguir após essa condição ser atendida.

Nessa estrutura, cada parâmetro precisa responder a duas perguntas: de onde vem esse valor na hora da execução, e quais condições precisam ser satisfeitas antes de usá-lo. Assim, um batch deixa de ser uma simples lista de transações e passa a ser um programa com verificações embutidas.

Em resumo, o modelo de pensamento do processamento em batch estático é uma lista — executar A, depois B, depois C; já o do ERC-8211 é um programa condicional — após executar A, usar seu resultado real para determinar B; verificar restrições antes de passar para C; e assim por diante, revertendo tudo se alguma etapa não atingir o esperado.

Podemos entender isso como uma “execução inteligente” especialmente pensada para Agentes de IA e operações complexas de DeFi, que na operação tradicional exigiriam múltiplas transações independentes: retirar fundos de um protocolo de empréstimo, trocar tokens, depositar em outro protocolo, etc.

Cada passo requer assinatura e confirmação separadas, o que é trabalhoso para humanos e um gargalo para IA que opera com alta frequência. O ERC-8211 permite que múltiplas operações blockchain sejam agrupadas em uma única transação, com valores avaliados dinamicamente na hora, e só prosseguindo se as condições forem atendidas.

Por exemplo, um Agente pode fazer tudo numa única assinatura: retirar fundos do Aave, trocar o valor recebido na Uniswap, e depositar no Compound — tudo de forma atômica, sem precisar criar novos contratos inteligentes.

III. Por que isso tem maior relação com carteiras, especialmente carteiras inteligentes?

O ERC-8211 merece atenção da indústria de carteiras não só por ser adequado para Agentes, mas por redefinir o papel da carteira na interação com a cadeia.

Antigamente, a carteira era mais como um assinador seguro: guardava a chave privada, exibia transações, solicitava confirmação, e assinava. Essa função, na era do EOA, já era suficiente, e continua válida na era da abstração de contas. Mas se no futuro muitas operações na cadeia forem feitas por um Agente, o papel da carteira se tornará mais central e importante.

A razão é simples: ao invés do usuário controlar cada ação na cadeia, ele pode autorizar um Agente a executar um conjunto de tarefas. Nesse cenário, a carteira precisa ser capaz de suportar esse nível mais alto de interação, exibindo não apenas um endereço de contrato e uma calldata, mas uma “intenção — lógica de obtenção de valores — condições — resultado final” como um programa executável.

Portanto, o futuro das carteiras será entender não apenas transações, mas programas. O ERC-8211 fornece uma estrutura mais clara para isso, ao codificar explicitamente a origem dos parâmetros, as condições de execução, os pontos de continuação e rollback, tudo de forma interpretável, simular e exibir.

Do ponto de vista da carteira, esse mecanismo aponta para uma mesma direção: o usuário não assina mais uma sequência de chamadas que dificilmente consegue entender, mas uma representação de execução orientada a resultados, com limites claros e condições verificáveis:

• Agentes de IA podem interpretar a intenção do usuário e gerar um caminho;
• A carteira exibe esse caminho de forma clara para revisão;
• O relayer apenas envia a transação quando as condições forem atendidas, sem poder alterar o resultado.

Essa é a razão pela qual a execução sem custódia, baseada em expressões de intenção complexa, é vista como um pré-requisito para DeFi com agentes, pois o agente participa, mas a soberania, as restrições e a liquidação final permanecem na cadeia. É aí que o ERC-8211 se encaixa com carteiras inteligentes: ao incorporar a “expressão segura de intenções complexas” no padrão do protocolo.

Vale destacar que o ERC-8211 é compatível com ERC-4337, EIP-7702, ERC-7579 e outros frameworks de abstração de contas. Ele não substitui a abstração de contas, mas acrescenta uma camada de semântica programática à execução de agentes.

Se o ERC-4337 resolveu “quem pode iniciar uma transação em meu nome”, e o EIP-7702 abordou “como uma EOA pode temporariamente possuir capacidades de contrato inteligente”, o ERC-8211 resolve o seguinte: quando um Agente começa a agir em meu nome, ele pode fazer toda uma cadeia de decisões em uma única assinatura?

Para entender a evolução do paradigma de interação na Ethereum ao longo dos últimos 10 anos:

• Primeira fase: uma assinatura = uma chamada de função (Era EOA)
• Segunda fase: uma assinatura = um pacote de chamadas estáticas (ERC-4337, EIP-5792)
• Terceira fase: uma assinatura = um programa de avaliação dinâmica de intenções (ERC-8211)

Cada avanço permite que o usuário (ou seu agente) expresse objetivos mais complexos com menos fricção.

Embora o ERC-8211 ainda esteja em estágio de rascunho, com discussões técnicas em andamento e integração ampla ainda por vir, seu direcionamento já está claro: quando agentes de IA começarem a tomar decisões na cadeia, será necessário uma sintaxe de execução nativa, mais expressiva e segura.