Como agentes de IA realizam trades onchain: intenções e…

Como os agentes de IA executam negociações onchain se resume à infraestrutura, não à "magia da IA": o agente produz intenções assinadas que outros atores transformam em mudanças de estado do Ethereum. A negociação só é concluída se duas trilhas estiverem conectadas corretamente, a trilha de execução (transação EOA ou UserOperation ERC-4337) e a trilha de permissão de token (autorizações ou permissões estilo Permit2).

Principais Conclusões

• Um agente de IA não "negocia" por si só no Ethereum. Ele deve controlar ou ser autorizado por uma conta onchain que pode acionar chamadas de contrato e transferências de token.
• Existem duas trilhas de execução: uma transação originada em EOA, ou uma UserOperation ERC-4337 que um bundler envia para o contrato EntryPoint para verificação e execução.
• Trocas requerem permissão explícita de gasto de token antes do movimento de token, e Permit2AllowanceTransfer adiciona expirações e nonces por (proprietário, token, gastador) para limitar e proteger contra repetição essa permissão.
• Para tamanhos maiores ou controles mais rigorosos, um Safe pode separar funções permitindo que o agente proponha uma transação enquanto múltiplos proprietários confirmam antes da execução.

Como um agente de IA pode negociar onchain

A saída de um modelo não é uma ação onchain. A cadeia apenas reage a mensagens que passam por verificações de assinatura e chamam contratos de uma conta que possui ativos.Essa é a realidade central por trás da negociação autônoma onchain: o “agente” é um motor de decisão offchain, e a parte onchain é uma conta mais um pedido assinado que a rede aceitará.

Duas trilhas aparecem em um explorador de blocos. A primeira é a trilha de execução, significando como o pedido se torna uma transação Ethereum. No Ethereum, apenas uma Conta Externamente Possuída pode originar uma transação, porque uma EOA é controlada por uma chave privadae assina a transação diretamente. Um contrato inteligenteA conta pode manter ativos e executar lógica, mas não pode originar uma transação por conta própria. Ela só realiza trabalho quando é chamada por algo mais.

O segundo trilho é o movimento de tokens. UmDEXswap não é “apenas chamar um roteador.”ERC-20tokens não se movem porque uma função de troca foi chamada. Eles se movem porque o proprietário do token concedeu autoridade de gasto a algum gastador, e então esse gastador usa essa autoridade para transferir tokens.

Se o agente está construindo a execução de agente onchain que toca em ERC-20s, ele precisa resolver ambas as ferrovias toda vez: (1) fazer a cadeia executar chamadas, e (2) garantir que o contrato certo esteja autorizado a retirar a quantidade certa de tokens.

É aqui que os produtos DeFi se agrupam: execução autônoma envolta na experiência do usuário da carteira, com limites em torno do que é assinado e do que é gasto. O modelo mental útil é o mesmo por trás da execução on-chain autônoma do DeFi como uma categoria: o agente cria intenções, e a infraestrutura transforma essas intenções em liquidação.

O pipeline de execução ERC-4337

ERC-4337 transforma "enviar uma transação" em uma cadeia de suprimentos com atores adicionais, e isso muda as suposições de confiabilidade. Em vez de um EOA transmitindo uma transação para o mempool público, uma carteira ERC-4337 constrói um objeto UserOperation e o entrega a um bundler que mais tarde envia uma transação onchain para um contrato EntryPoint singleton.

O fluxo de ponta a ponta é mais fácil de acompanhar como uma sequência:

1. O agente prepara uma carga útil. Para uma carteira de agente que é uma conta inteligente ERC-4337, a carga útil é uma UserOperation com campos como remetente, nonce, callData,gáslimites, parâmetros de taxa e uma assinatura. 2. O agente envia a UserOperation para um mempool alternativo. As carteiras normalmente a enviam para um endpoint RPC de bundler em vez do pool de transações padrão do Ethereum. 3. Um bundler coleta e simula.

Bundlers monitoram o alt-mempool, simulam UserOperations candidatas e decidem quais incluir em um bundle. 4. O bundler origina a transação onchain. O bundler chama EntryPoint.handleOps com um array de UserOperations, e essa chamada é a transação Ethereum real que entra em um bloco. 5. EntryPoint verifica e, em seguida, executa.

EntryPoint segue um padrão de duas fases: chama validateUserOp na conta (e validatePaymasterUserOp se um paymaster estiver anexado) e só então executa a fase de execução. 6. O gás é liquidado via prefundos ou um paymaster. O ERC-4337 permite que um contrato Paymaster patrocine o gás reembolsando o bundler sob regras definidas.

Paraagente de negociação de IANa mecânica, o ponto chave não é o formato da assinatura. É quem é responsável pela inclusão. Com o ERC-4337, "executado pelo agente" não é quando o agente assina. É quando o EntryPoint executa, e isso depende do comportamento do bundler e das regras do paymaster se o gás for patrocinado.

Como os agentes obtêm permissão para gastar tokens

O movimento de tokens é onde a maioria dos designs de agentes vaza risco, porque as permissões tendem a sobreviver ao comércio. O modelo limpo é permissão primeiro, execução em segundo lugar. O ERC-4337 pode comprimir isso em uma única liquidação, agrupando várias ações em uma única UserOperation, mas a concessão de permissões ainda precisa ser explícita e limitada.

UniswapO Permit2 AllowanceTransfer é um conjunto concreto de primitivas para esta camada. Ele suporta três pontos de entrada principais: approve (definir permissões onchain), permit (definir permissões via uma assinatura) e transferFrom (gastar quando permissões válidas já existem).

A diferença importante em relação ao antigo hábito de “aprovar máximo para sempre” é que as permissões do Permit2 podem ser limitadas no tempo usando um timestamp de expiração.

Permit2 também oferece um mecanismo prático de proteção contra replay que os agentes podem realmente usar. Seu esquema de nonce incrementa nonces por proprietário, por token e por gastador, agrupados em um mapeamento de autorização. Isso significa que uma permissão não é apenas "o proprietário assinou uma vez", mas "o proprietário assinou esta janela de gasto específica para este gastador, e esse nonce já foi consumido."

A permissão do Permit2 suporta assinaturas EOA, assinaturas compactas EIP-2098 e assinaturas de contrato EIP-1271, o que é importante quando o proprietário é uma conta inteligente em vez de uma EOA.

Para como os agentes negociam DeFi, este é o padrão operacional que aparece quando as coisas são construídas cuidadosamente:

1. O agente solicita uma janela de gasto estreita. O valor é limitado, a expiração é curta, o gastador é específico. 2. O agente empacota a permissão com a execução. Uma permissão ou aprovação pode ser combinada com a chamada de troca para que a autorização não fique parada sem uso. 3. O agente gasta via transferFrom apenas dentro daquela janela. Se a janela expirar, a permissão está morta na cadeia.

Este também é o lugar onde a execução baseada em intenção e uma rede de solucionadores se encaixam conceitualmente. O agente pode assinar uma intenção que expressa o resultado desejado, enquanto os solucionadores competem para roteá-la e liquidá-la. Independentemente de quem roteia, a ferrovia de permissão de token ainda decide o que pode ser retirado da conta do proprietário.

Multisig e controles de política com Safe

O padrão de controle mais robusto para dinheiro real é a separação de políticas: deixe o agente propor, mas exija um limite do Safe para executar. Isso mantém a automação enquanto remove a autoridade unilateral de uma única chave de execução do modelo.

O fluxo documentado do Safe é explícito sobre as transferências. Uma transação é criada, proposta ao Serviço de Transação Safe, confirmada por outros proprietários e só então executada. No guia do Safe Protocol Kit, a sequência é: criar um objeto de transação, calcular o hash da transação Safe, propor para que outros proprietários possam vê-la, coletar confirmações (assinaturas) dos proprietários e, em seguida, executar com executeTransaction.

Isso é importante para a execução autônoma porque muda o que "ação do agente" significa. O agente pode gerar o calldata exato para uma chamada de roteador DEX, ou para um executeBatch de uma conta ERC-4337, mas o Safe é a mesa de risco que decide se essa carga útil pode atingir a cadeia.

Este é um lugar limpo para impor políticas que as fontes não padronizam para os agentes, como limitar novos gastadores, exigir confirmações extras para novos tokens ou restringir tamanhos.

O Safe também se adapta bem a padrões de chave de sessão na camada de conta. Contas ERC-4337 podem validar diferentes esquemas de assinatura dentro de validateUserOp, e uma chave de sessão pode ser um desses esquemas. O ponto não é a palavra da moda. O ponto é que uma chave de curta duração pode ser autorizada para ações restritas enquanto os proprietários de longo prazo mantêm o controle final.

Para equipes que constroem sistemas defai, essa é a diferença entre "o agente pode negociar" e "o agente pode elaborar negociações." Elaborar é barato. A execução é onde ocorrem mudanças de estado irreversíveis.

Compromissos de design e modos de falha

O primeiro modo de falha é a confusão entre tipos de mensagens. Um UserOperation não é uma transação Ethereum. É um dado em um mempool alternativo até que um bundler o envolva em uma chamada EntryPoint.handleOps. É por isso que contas de contratos inteligentes não podem “simplesmente enviar transações como EOAs.” Apenas EOAs originam transações, e contas inteligentes agem quando são chamadas.

O segundo modo de falha é tratar o bundler como uma infraestrutura invisível. O ERC-4337 muda as suposições de “minha carteira transmite” para “um bundler me incluirá.” A descrição da Eco é explícita ao afirmar que os bundlers observam o alt-mempool, simulam e enviam pacotes, pagando gás L1 e sendo reembolsados a partir de prefunds ou paymasters.

Se um endpoint de bundler estiver fora do ar, limitado por taxa ou recusando certas operações, o agente pode continuar assinando e nada será liquidado.

O terceiro modo de falha é a expansão de permissões. Aprovações ilimitadas não são uma característica de negociação. Elas são uma superfície de perda constante. Os timestamps de expiração do Permit2 e os nonces por-(proprietário, token, gastador) são os controles onchain que podem limitar essa superfície, mas apenas se a integração os utilizar.

Um erro comum de integração é autorizar o gastador errado ou passar o "from" errado.endereçoem uma chamada de transferência, que a Uniswap sinaliza como uma consideração de segurança para a integração de contratos.

O quarto modo de falha é o excesso de crédito à IA. A maioria das falhas na execução de agentes onchain vem da conexão, não do modelo escolher o lado errado. Se a carteira do agente puder assinar uma permissão ampla, ou se as regras do pagador forem muito flexíveis, o sistema pode fazer exatamente o que foi autorizado a fazer e ainda assim ser inaceitável.

O resumo das compensações é direto. EOAs são simples e diretas, mas colocam todo o sistema atrás de uma chave. O ERC-4337 adiciona agrupamento, validação personalizada e gás patrocinado, mas introduz uma cadeia de suprimento de transações com agrupadores, EntryPoint e pagadores opcionais. O Safe adiciona atrito por design, e esse atrito é o ponto em que o tamanho importa.

Perto do final de qualquer documento de arquitetura sério, o tópico mais amplo ainda é a execução autônoma onchain, e a questão é qual trilho e qual camada de política o sistema pode realmente suportar sob estresse.

A Análise

Eu vi equipes se obsessarem pela parte de “IA” e depois lançarem o erro caro: uma aprovação de token ampla e de longa duração emparelhada com uma infraestrutura frágil. Quando algo dá errado, raramente é porque o modelo alucina uma negociação. É porque a camada de permissão permitiu que um gastador retirasse mais do que o pretendido, ou porque a cadeia de suprimentos ERC-4337 parou no agrupador e ninguém estava monitorando a inclusão.

A postura limpa é tratar isso como um diagrama de duas chaves a cada vez: autoridade de execução e autoridade de gasto. Se o design não consegue responder, em uma frase, quem origina a transação (EOA vs bundler via EntryPoint) e exatamente o que o gastador pode retirar (quantia, expiração, escopo de nonce), então o sistema não é “autônomo.” Ele é apenas não supervisionado.

Fontes

• QuickNode
• Eco
• Uniswap
• Safe