Como funcionam agentes de IA em cripto: leitura de dados e…

Agentes de IA em cripto funcionam executando um loop de agente que transforma prompts em consultas de dados estruturados onchain, e então roteia qualquer ação proposta através de regras de carteira programáveis antes que uma transação possa ser executada. A parte útil não é "o bot negocia", é a fronteira de permissão entre inteligência somente leitura e execução onchain.

Principais Conclusões

• Agentes cripto se tornam utilizáveis quando "inteligência" é separada de "execução": chamadas de ferramentas de análise estruturada de um lado, autorização de conta inteligente do outro.
• O servidor MCP da Dune expõe 12 ferramentas através de um único endpoint para que um agente possa descobrir tabelas, gerar DuneSQL, executar consultas e retornar resultados consumíveis por máquina em mais de 100 blockchains.
• Contas Inteligentes Seguras substituem EOAs de chave única com proprietários mais um limite, e podem ser estendidas com módulos críticos de segurança e guardas que também podem falhar de maneiras complicadas.
• O suporte a cadeias não é uniforme, então uma pilha de agentes que assume um módulo ou recurso específico do Safe pode funcionar em uma rede e estar indisponível em outra.

Como os agentes de IA se encaixam em cripto

Em uma tela, "agentes em cripto" geralmente parecem uma caixa de chat que pode puxar um gráfico, resumir fluxos e às vezes enfileirar uma transação. Por trás das cenas, o modelo mental limpo é um pipeline de duas chaves: um cérebro somente leitura que pode chamar ferramentas de análise estruturada, e um conjunto de "mãos" que só podem se mover quando as regras de uma conta inteligente permitem.

Essa estrutura responde à pergunta sobre o que são agentes de IA em cripto sem fingir que o agente é uma carteira mágica com opiniões.

O mecanismo no qual a maioria das equipes converge é o loop de agente perceber decidir agir, porque se encaixa perfeitamente na divisão entre dados e execução em cripto. Percepção não é "assistir a cadeia" no sentido humano. São chamadas de ferramentas que retornam saídas estruturadas. Decisão é a etapa de inferência do modelo sobre essas saídas mais qualquer política que você codifique.

Ação é uma proposta de transação ou uma execução onchain real, dependendo de como a fronteira de autorização é projetada.

Essa fronteira é onde cripto difere da automação genérica. Um agente SaaS normal pode ser dado um chave de API e limites de taxa. Um agente de IA cripto que pode assinar está a um prompt ruim de se tornar um evento de perda.

Portanto, a arquitetura que se sustenta é: (1) dar ao agente leituras confiáveis, chamáveis por máquina, e (2) dar a ele uma execução restrita através de uma conta inteligente que força aprovações explícitas, limites, ou ambos.

É também aqui que o "fluxo de trabalho agente" deixa de ser uma palavra da moda. O fluxo de trabalho é uma cadeia reprodutível de chamadas de ferramentas, saídas e intenções de transação, com um ponto claro onde um limite ou guarda seguro pode dizer "não."

Acesso de ferramentas a dados onchain

O servidor MCP da Dune é um exemplo concreto de como os agentes de IA funcionam quando não estão raspando painéis. Ele expõe 12 ferramentas através de um único ponto de extremidade para que um agente compatível com MCP possa descobrir tabelas, escrever DuneSQL, executar consultas, recuperar resultados e gerar visualizações contra o armazém da Dune em mais de 100 blockchains indexadas.

Isso é importante porque o agente não está mais adivinhando nomes de tabelas ou dependendo de capturas de tela. Ele está chamando funções que retornam resultados estruturados.

A sequência é direta, e é a parte que a maioria dos explicadores de "agentes leem dados e negociam" pula:

1. O agente pesquisa o catálogo da Dune por conjuntos de dados relevantes e tabelas de contratos decodificados. 2. Ele gera DuneSQL a partir do prompt, então executa a consulta através da interface da ferramenta. 3. Ele recupera resultados em um formato consumível por máquina e pode renderizar uma visualização se necessário.

O CLI da Dune leva a mesma ideia para a automação nativa de terminal. O CLI é construído para fluxos de trabalho de agentes e cobre descoberta de conjuntos de dados, escrita e execução de DuneSQL, gerenciamento de consultas, busca de documentos e rastreamento de uso.

Cada comando gera JSON para consumo por máquina, e vem com um arquivo Skills.md que segue um padrão de habilidades de agente para que um agente possa aprender capacidades e tratamento de erros sem integração personalizada.

Esta é a realidade da "arquitetura de agente de IA cripto": a estrutura do agente é tão boa quanto as ferramentas que pode chamar. Se a camada de ferramentas retorna SQL e saídas JSON reprodutíveis, o agente pode ser auditado e reexecutado. Se a camada de ferramentas é um painel e uma sensação, o agente está apenas improvisando.

Contas inteligentes como camada de execução de agente

A execução é onde os agentes de criptomoeda se tornam seguros o suficiente para usar ou perigosos o suficiente para evitar. O erro comum é dar automação a um EOA. Os EOAs são controlados por uma única chave privada, e se alguém obtiver essa chave, terá controle total. Esse é um modelo de segurança limpo para um humano com uma carteira de hardware. É um modelo frágil para software que opera sem supervisão.

As Contas Inteligentes mudam o modelo de autorização. Elas podem receber fundos e realizar transações como os EOAs, mas não podem iniciá-las. Sua lógica de verificação e execução é definida pelo código de contrato inteligente em vez de uma única chave privada. Esse detalhe é o motivo pelo qual as contas inteligentes são a camada natural de “carteira de agente”. A própria conta se torna um motor de políticas.

A Conta Inteligente Segura é a implementação mais conhecida dessa ideia. É uma Conta Inteligente com multisignatura em seu núcleo: um conjunto de proprietários e um limite de confirmações necessárias antes da execução. Os proprietários podem ser EOAs, outras contas de contrato inteligente ou até mesmo uma chave de acesso.

Para um agente, isso significa que a postura padrão pode ser “o agente prepara, um humano co-assina,” e o sistema ainda usa o mesmo endereço on-chain e contabilidade.

A arquitetura do Safe também é importante para implantação e operações. As Contas Inteligentes do Safe são implantadas usando um padrão de proxy onde um Proxy do Safe delega chamadas a um contrato singleton do Safe, o que reduz o custo de implantação. A Fábrica de Proxy do Safe pode criar um proxy e executar a configuração em uma única transação. Nada disso é "IA", mas é a infraestrutura que torna a automação controlada viável.

Controles programáveis para uma automação mais segura

As superfícies de controle que realmente fazem a automação funcionar estão dentro do Safe, não dentro do modelo. O limite multi-sig do Safe é o instrumento contundente. Módulos e guardas são os bisturis, e o Safe os marca como críticos para a segurança por uma razão.

Os módulos estendem o que um Safe pode fazer, permitindo padrões de acesso alternativos e permissões granulares. A documentação do Safe cita exemplos como limites de autorização e fluxos de recuperação, e é explícito que um Safe básico não requer nenhum módulo.

Adicionar ou remover um módulo requer confirmação pelo limite do proprietário, e os módulos precisam ser tão seguros quanto o restante dos contratos do Safe, pois podem expandir o que é executável.

Os guardas são uma alavanca diferente. Um guarda pode aceitar ou rejeitar transações com base na lógica do guarda. O Safe também alerta que os guardas são críticos para a segurança e que um guarda malicioso poderia impedir a execução de transações e bloquear o acesso a fundos armazenados no Safe. Esse é o modo de falha que as pessoas perdem quando tratam os guardas como "segurança extra". Um guarda é um contrato de porteiro. Se estiver errado ou hostil, o Safe pode ficar operacionalmente bloqueado.

O Safe também suporta transações patrocinadas e pagamento baseado em token de gas via um serviço de retransmissão que aceita tokens ERC20 suportados e envia transações enquanto paga gas em ETH. O mesmo caminho de retransmissão pode ser usado para fluxos sem ether, onde uma terceira parte paga as taxas em nome de um Safe. Para sistemas de agentes, isso é menos sobre conveniência e mais sobre design operacional. Se espera-se que o agente envie transações, as suposições de gás e retransmissão fazem parte da fronteira de permissão.

É aqui que o “loop de agente cripto” se torna concreto: percepção e inferência podem ser rápidas e baratas, mas a ação é uma transação que deve passar por verificações de limite, permissões de módulo e lógica de guarda antes de atingir a cadeia.

Considerações sobre implantação e suporte à rede

Muitos designs de agentes falham por uma razão entediante: assume-se que a pilha é uniforme entre as cadeias. O Safe publica uma lista de redes suportadas que mostra versões de Smart Account e disponibilidade de recursos ou módulos por cadeia, incluindo módulos como Safe 4337, Safe Passkey e Safe Recovery.

A página é efetivamente uma matriz de compatibilidade, e isso importa porque “vamos apenas usar o módulo X” não é um plano se a cadeia alvo não o suportar.

Mesmo dentro do ecossistema Safe, as versões diferem por rede. A lista de redes suportadas mostra várias versões de Smart Account (por exemplo, v1.5.0, v1.4.1, v1.3.0 e versões anteriores) e então sinaliza quais serviços e módulos estão disponíveis em cada cadeia. Esse é o tipo de detalhe que decide se um fluxo de trabalho agente pode ser implantado conforme projetado ou precisa de uma postura de execução diferente.

É também aqui que as duas metades do pipeline precisam ser verificadas separadamente. O post MCP da Dune descreve o acesso em mais de 100 blockchains, enquanto o post CLI nativo de agente da Dune descreve o acesso em mais de 130 cadeias. Essa discrepância não é um problema por si só, mas é um lembrete para tratar a “cobertura da cadeia” como um item a ser verificado, não como uma cópia de marketing.

Uma lista de verificação operacional mínima emerge:

1. Confirmar que a camada de dados cobre a cadeia alvo e as tabelas de protocolo específicas necessárias para a etapa de percepção do agente. 2. Confirmar que a camada de execução suporta a versão do Safe e os módulos ou recursos específicos dos quais a política depende. 3. Somente então projetar a ponte entre eles, porque a ponte é onde as permissões e modos de falha residem.

Limites e riscos abertos a serem observados

As fontes descrevem blocos de construção poderosos, mas não fornecem uma única arquitetura de referência de ponta a ponta para um agente autônomo que analisa e executa. Essa lacuna importa porque a autonomia não é um interruptor. É um espectro, e o ponto seguro nesse espectro depende de quanta autoridade a camada de execução concede.

Dois limites aparecem imediatamente. Primeiro, o acesso às ferramentas é tão bom quanto sua estrutura. O MCP e o CLI da Dune são projetados para retornar saídas consumíveis por máquinas, o que é a direção certa, mas as fontes não quantificam confiabilidade, taxas de erro ou com que frequência os agentes geram consultas incorretas que ainda retornam resultados com aparência plausível.

Em segundo lugar, os pontos de extensão do Safe são explicitamente críticos para a segurança. Módulos podem ampliar permissões de execução, e guardas podem bloquear a execução completamente. Esses não são riscos abstratos. Eles são restrições de design.

Há também um limite de governança e operações que é ignorado nos ciclos de hype. Se um agente depende de um módulo, guarda ou caminho de retransmissão específico, então mudanças de política, atualizações ou lacunas de suporte específicas da cadeia se tornam parte da superfície de risco do agente. A matriz de redes suportadas do Safe existe porque a disponibilidade de recursos não é uniforme.

Finalmente, a conversa sobre “TEE” tende a ser considerada uma solução para tudo. Um tee pode ajudar a isolar segredos e atestar a execução de código, mas não substitui a necessidade de um limite de permissão de conta inteligente. Mesmo com uma custódia de chave mais forte, o erro caro ainda é dar ao software um único ponto de falha e autoridade ilimitada.

Agentes de criptomoeda estão se tornando reais porque a infraestrutura está se tornando real. A parte difícil ainda é a mesma: separar inteligência da execução, e então restringir a ponte para que o sistema possa ser confiável com capital.

A Conclusão

Eu vi equipes se obsessarem pela escolha do modelo e ignorarem a parte que realmente decide se um agente é utilizável: o limite de autorização. No momento em que um agente pode propor e executar a partir de um EOA de chave única, todo o sistema herda o pior modelo de segurança possível para automação. Uma chave vazada, um host comprometido, uma má integração, e tudo acaba.

O que eu vi funcionar é tratar ferramentas estruturadas no estilo Dune como o cérebro somente leitura, forçando a execução através de um limite do Safe até que o fluxo de trabalho prove seu valor. Módulos e guardas são onde a automação se torna real, e o Safe é explícito ao afirmar que eles são críticos para a segurança. Essa é a postura que impede que “agentes em cripto” se tornem uma interface sofisticada para assinar erros.

Fontes

• Dune
• Dune
• Documentos Seguros
• Documentos Seguros