Quando as carteiras começam a incorporar o Agente 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 habituar a uma nova forma de interação: dizer ao GPT ou Gemini uma frase como “Ajude-me 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 final 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 no Aave”, objetivamente, do ponto de vista de “entender a necessidade” e “planejar o caminho”, o Agent 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 Agent.

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 no quebra-cabeça.

1. A última lacuna na integração do AI Agent 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 uma questão mais disruptiva: como o AI Agent pode realmente assumir operações na cadeia.

Objetivamente, de “usar linguagem natural para emitir estratégias multi-step de DeFi” a “deixar um Agent autônomo gerenciar uma carteira de investimentos cross-chain”, temos visto várias implementações práticas, e a maioria dessas ideias já amadureceu em demonstrações, incluindo geração de estratégias DeFi em linguagem natural, execução autônoma de reequilíbrios, migração automática de lucros, ajuste 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 do AI já evoluiu bastante, mas quando realmente colocamos isso em produção, as limitações na camada de execução ficam cada vez mais evidentes.

Se for para colocar em produção, essa limitação pode ser resumida em uma frase: DeFi é dinâmico, mas a maioria dos batchs (processamentos em lote) atuais ainda são estáticos.

O site oficial e os fóruns do ERC-8211 deixam isso bem claro: embora os ERC-4337 e EIP-5792 tenham levado o paradigma antigo de “uma assinatura corresponde a uma chamada” para um novo estágio de “uma assinatura pode agrupar múltiplas chamadas”, na prática, os parâmetros dessas chamadas ainda permanecem 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 no estado da cadeia durante a execução.

Porém, DeFi é justamente 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 Agent veem na assinatura muitas vezes são apenas estimativas momentâneas, não resultados reais durante a execução.

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

Sob o modelo de processamento em batch estático atual, o Agent precisa estimar na 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 problemas se o valor real recebido for menor do que o estimado, causando rollback do batch; ou, se estimar demais, deixar fundos ociosos 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 difícil de descrever, mas porque o paradigma de execução atual depende demais de parâmetros fixos.

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

Dessa perspectiva, o que o ERC-8211 busca resolver não é a decisão do AI Agent, 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 primeira execução na cadeia teria uma expressão nativa para agentes de IA.

2. O que exatamente o ERC-8211 mudou?

A inovação central do ERC-8211 não está em colocar mais etapas 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 não é difícil de entender: a equipe usou uma frase para descrevê-lo como: “De transações a programas”.

Isso significa que o ERC-8211 não trata mais 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 o parâmetro será obtido, podendo ser uma consulta ao saldo atual de um endereço, fazendo com que o valor não seja 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 extrair 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%”, e qualquer uma dessas restrições não sendo atendida faz o batch inteiro reverter;
• Predicates (predicados): atuam como guardiões entre etapas, não gerando valores, mas decidindo se o processo deve continuar, como em cenários cross-chain, onde o batch na Ethereum só avança após o predicate verificar “WETH recebido na ponte já chegou”.

Nessa estrutura, cada parâmetro responde a duas perguntas: de onde vem esse valor na execução e quais condições ele precisa atender antes de ser usado na chamada. Com isso, um batch deixa de ser apenas uma lista de transações e passa a ser um programa com verificações embutidas de segurança.

Em resumo, o paradigma de batch estático é uma lista — executar A, depois B, depois C. Já o de ERC-8211 é um programa condicional — após executar A, usar seu resultado real para B, que só prossegue se as restrições forem atendidas, e assim por diante, com rollback se alguma etapa falhar.

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

Cada passo requer assinatura e confirmação, o que é trabalhoso para humanos e um gargalo para agentes autônomos de alta frequência. O ERC-8211 permite que várias operações em diferentes blockchains sejam agrupadas numa única transação, com valores avaliados dinamicamente na execução e condições pré-definidas para continuar.

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

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

O motivo pelo qual o ERC-8211 merece atenção do setor de carteiras não é só por ser útil para Agents, 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 sendo na era da abstração de contas. Mas se no futuro muitas operações na cadeia forem feitas por um Agent, o papel da carteira se torna ainda mais central.

A razão é simples: ao invés do usuário controlar cada ação na cadeia, ele autoriza um Agent 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, as carteiras do futuro precisarão entender não apenas transações, mas programas. O ERC-8211 fornece uma camada mais clara para isso, ao codificar explicitamente a semântica de execução: de onde vêm os parâmetros, quais condições devem ser atendidas, quando continuar, quando reverter. Tudo isso não fica escondido em lógica de backend, mas é um objeto que a carteira pode interpretar, 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 série de chamadas de baixo nível difíceis de entender, mas uma expressão de resultado, com limites claros e condições verificáveis:

• O AI Agent pode entender a intenção do usuário e gerar um caminho;
• A carteira exibe esse caminho de forma mais 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 não custodial, baseada em expressões de intenção complexa, é vista como uma pré-condição para o DeFi com agentes — porque o agente participa, mas a soberania, as restrições e a liquidação final permanecem na cadeia.

O ERC-8211, portanto, se encaixa perfeitamente na ideia de que “segurança na expressão de intenções complexas” deve estar no padrão do protocolo.

Vale destacar que o ERC-8211 é compatível com ERC-4337, EIP-7702, ERC-7579, entre 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 para agentes.

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

Revisitando 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 Agent) expresse objetivos mais complexos com menos fricção.

Embora o ERC-8211 ainda esteja em fase de rascunho, com discussões técnicas em andamento, e sua adoção em larga escala ainda leve tempo, 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 e compatível.