Pular para o conteúdo
0%

O que é ERC-8004? Como agentes trustless funcionam na Ethereum

Uttam Singh headshot

Escrito por Uttam Singh

Publicado em 9 de setembro de 20269 min de leitura

Imagem de capa do guia sobre agentes trustless ERC-8004

ERC-8004, chamado de Trustless Agents, é um padrão Ethereum que dá a agentes de IA uma identidade onchain, um registro público de reputação e uma forma de ter seu trabalho verificado, para que possam transacionar entre organizações sem confiança pré-existente. Este guia explica como funcionam seus três registries, o que de fato está implantado na mainnet hoje, como o padrão se encaixa com A2A, MCP e x402, e o que observar antes de construir sobre ele.

O que é ERC-8004?

O ERC-8004 foi proposto em agosto de 2025 por autores da MetaMask, da Ethereum Foundation, do Google e da Coinbase, e define três registries. O Identity Registry registra quem é um agente. O Reputation Registry registra o que seus clientes dizem sobre ele. O Validation Registry registra se validadores independentes verificaram seu trabalho.

A especificação é explícita ao dizer que confiança não é algo único para todos os casos. Em suas próprias palavras, os modelos de confiança são "plugáveis e escalonados, com segurança proporcional ao valor em risco, desde tarefas de baixo risco como pedir uma pizza até tarefas de alto risco como diagnóstico médico." Um agente que reserva uma mesa em um restaurante pode se apoiar em pontuações de reputação. Um agente que gerencia uma tesouraria precisa que seu trabalho seja reverificado por alguém com dinheiro em risco.

Por que agentes de IA precisam de uma camada de confiança?

Todo sistema de confiança que você usa hoje pressupõe uma plataforma no meio. Avaliações de marketplace vivem no banco de dados de uma única empresa. Estornos existem porque uma rede de cartões fica entre comprador e vendedor. Logins via OAuth funcionam porque um grande provedor de identidade responde por você. Esse modelo não funciona para agentes autônomos, que são construídos para operar entre empresas, nuvens e jurisdições sem um operador em comum.

O restante da stack de agentes preencheu essa lacuna. O Model Context Protocol (MCP) conecta um agente a ferramentas e fontes de dados. O Agent2Agent (A2A) permite que agentes se encontrem e troquem mensagens estruturadas. O x402 permite que paguem por serviços via HTTP simples. Cada um desses pressupõe que você já decidiu com qual contraparte trabalhar. Nenhum deles ajuda você a tomar essa decisão.

Esse é o trabalho que o ERC-8004 assume, e é por isso que os registries vivem em uma blockchain em vez de no banco de dados de alguém. Um agente DeFi escolhendo uma venue de execução, um agente de pesquisa contratando um agente de rotulagem de dados, e um comerciante decidindo se atende um comprador desconhecido, todos precisam das mesmas três consultas. Quem é esse agente? O que aconteceu quando outros trabalharam com ele? Alguém verificou sua produção? O ERC-8004 coloca essas respostas em algum lugar que nenhuma parte isolada controla, em um único schema que todo agente pode ler.

Como funciona o identity registry do ERC-8004?

Cada agente registrado é um token ERC-721, o mesmo padrão por trás dos NFTs. Registrar-se chama register() no Identity Registry e cunha um token cujo ID se torna o número do agente. O identificador completo do agente combina a chain e o endereço do registry com esse ID, de modo que "agente 4.205 na Base" é inequívoco globalmente.

O URI do token aponta para um arquivo de registro, hospedado no IPFS, via HTTPS ou embutido diretamente onchain, que descreve o que é o agente e como alcançá-lo. Um arquivo de registro simplificado se parece com isto:

json
Copied
{ "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1", "name": "Research Agent", "description": "Fetches and summarizes onchain data on request", "image": "ipfs://<image-hash>", "services": [ { "name": "A2A", "endpoint": "https://agent.example/a2a" }, { "name": "MCP", "endpoint": "https://agent.example/mcp" } ], "supportedTrust": ["reputation", "tee-attestation"] }

O array services é o payload de descoberta. Ele anuncia os endpoints ativos do agente em quaisquer protocolos que ele fale, incluindo A2A, MCP, nomes ENS e identificadores descentralizados. O campo supportedTrust declara quais modelos de confiança o agente adota. A especificação observa que, se estiver ausente, o registro é usado apenas para descoberta.

Construir sobre o ERC-721 traz muita coisa de graça. Propriedade, transferência e delegação já funcionam, carteiras e marketplaces já renderizam os tokens, e o tooling do ecossistema se aplica sem alterações. O registry também separa a identidade das chaves que agem no dia a dia. setAgentWallet vincula uma carteira operacional ao agente com uma autorização assinada, de modo que o dono do token de identidade e a carteira que assina transações podem ser chaves diferentes com raios de impacto diferentes. É a mesma separação que recomendamos ao dar uma carteira a um agente, em que o agente recebe acesso de assinatura escopado e limitado no tempo em vez de uma chave privada crua.

Como funciona o reputation registry do ERC-8004?

Qualquer endereço pode avaliar qualquer agente chamando giveFeedback no Reputation Registry. Uma entrada de feedback carrega um valor numérico assinado com casas decimais configuráveis, de modo que as pontuações podem ser negativas e precisas em vez de uma escala grosseira de um a cinco, além de até duas tags para filtragem e um URI opcional apontando para um texto offchain mais completo, registrado onchain pelo seu hash. A única restrição rígida é que o dono e os operadores de um agente não podem avaliar o próprio agente.

Duas decisões de design importam mais do que as assinaturas das funções. Primeiro, os clientes nunca se registram em lugar nenhum, o que mantém a barreira para deixar feedback em zero e permite que serviços patrocinem o gas das avaliações de seus usuários. Segundo, o registry deliberadamente não calcula nenhuma pontuação canônica. Ele armazena sinais brutos, oferece funções de resumo e de leitura, e deixa a interpretação para quem quer que consulte os dados. Discussões sobre a proposta argumentaram desde cedo que um único número agregado de reputação convida a dinâmicas de monopólio e manipulação, então a pontuação vive na camada do indexador, onde diferentes consumidores podem ponderar os mesmos dados de formas diferentes.

O arquivo de feedback offchain é onde as avaliações ganham força. Ele pode referenciar as ferramentas MCP exatas ou as tarefas A2A exatas usadas na interação, e pode embutir a prova de um pagamento x402, vinculando a avaliação a uma transação que verificavelmente aconteceu. Uma avaliação respaldada por um recibo de pagamento é um sinal muito mais forte do que uma pontuação simples vinda de uma carteira anônima, e filtrar exatamente por esse tipo de avaliação é como se espera que consumidores sérios do registry o usem.

Como funciona o validation registry do ERC-8004?

Pontuações de feedback dizem o que clientes anteriores pensaram. Para trabalhos de maior valor, isso não basta, e a própria produção precisa ser verificada. O Validation Registry permite que um agente peça que um validador nomeado verifique um trabalho específico: validationRequest registra o validador, o agente e um ponteiro comprometido por hash para o trabalho, e o validador responde com validationResponse, pontuando o resultado de 0 a 100 com sua própria evidência comprometida por hash.

O que "verificar" significa depende do validador. Pode reexecutar a tarefa e comparar as saídas, com stake que perde se atestar de forma desonesta. Pode atestar que o agente rodou dentro de um trusted execution environment (uma TEE, hardware que consegue provar qual código executou). Pode verificar uma prova de zero-knowledge machine learning (zkML, uma prova criptográfica de que um modelo específico produziu uma saída específica). O registry não se importa com qual deles; ele padroniza apenas o encanamento de requisição e resposta.

Uma ressalva do estado atual que quase nenhuma cobertura menciona. A implantação oficial multi-chain traz os registries de Identity e Reputation, mas o Validation Registry foi retirado para retrabalho junto à comunidade de TEE e não faz parte do conjunto oficial de mainnet hoje. Times que precisam de validação agora a conectam por meio de provedores específicos, como a integração de trustless agents da EigenCloud, que combina identidade ERC-8004 com sua própria computação verificável. Consulte o repositório oficial de contratos para saber onde a implantação está antes de construir sobre ele.

Qual modelo de confiança um agente deve usar?

O enquadramento de valor em risco da especificação se traduz em uma regra de decisão bastante clara. Equipare o custo da verificação ao custo de errar.

Trust model
How it works
Fits
Reputation
Clients post signed feedback onchain after each interaction
Low-stakes, high-volume tasks
Crypto-economic validation
Staked validators re-run the work and lose stake for false attestations
Higher-value tasks with checkable outputs
TEE attestation
Hardware proves which code the agent actually ran
Tasks where process integrity matters, like key handling
zkML proofs
A cryptographic proof that a specific model produced the output
Highest assurance, currently the most expensive

Os modelos também se combinam. Um agente em produção pode rodar em uma TEE, carregar um histórico de reputação e submeter saídas de alto valor para reexecução com stake, apresentando os três sinais por meio da mesma declaração supportedTrust.

Como ERC-8004, A2A, MCP e x402 se encaixam?

O stack de agentes: MCP, A2A e x402 com ERC-8004 como camada de confiança onchain

A stack de agentes é mais fácil de entender como quatro camadas com quatro donos diferentes. O MCP, da Anthropic, conecta um agente a ferramentas e contexto. O A2A, iniciado pelo Google, cuida da descoberta e da troca de mensagens entre agentes. O x402, conduzido pela Coinbase, movimenta o dinheiro, um dos vários protocolos de pagamento para agentes concorrentes. O ERC-8004 ancora a confiança, e é deliberadamente a única camada que vive em uma blockchain, porque identidade e reputação só são úteis se nenhuma contraparte as controla.

Uma única interação pode tocar as quatro camadas. Um agente comprador consulta o Identity Registry por agentes que anunciam a habilidade de que precisa, busca o arquivo de registro de um candidato e verifica seu resumo de reputação e suas validações. Ele abre uma sessão A2A para negociar a tarefa, ou chama diretamente o endpoint MCP do vendedor. Ele paga a fatura x402 que o vendedor retorna. Quando o trabalho é concluído, ele chama giveFeedback com uma referência ao pagamento, e o próximo cliente em potencial do vendedor vê uma avaliação com um recibo anexado.

Nada na stack exige o ciclo completo. Times adotam x402 sem ERC-8004, e registram identidades sem nunca pedir validação. Mas as camadas foram desenhadas para se referenciar. O arquivo de registro lista endpoints A2A e MCP, e os arquivos de feedback embutem recibos x402, de modo que compô-los exige configuração em vez de código de integração.

Como construir sobre o ERC-8004?

Ler os registries não exige tooling especial, porque são contratos comuns. As consultas de identidade são chamadas ERC-721, e cada registry emite eventos que você pode indexar. Atendemos todas as principais chains de implantação, então um endpoint RPC padrão já basta para começar. Buscar o arquivo de registro de um agente exige uma única leitura:

typescript
Copied
import { createPublicClient, http } from "viem"; import { mainnet } from "viem/chains"; const client = createPublicClient({ chain: mainnet, transport: http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"), }); // The Identity Registry is an ERC-721; tokenURI returns the agent's registration file URI const agentURI = await client.readContract({ address: "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432", abi: [ { name: "tokenURI", type: "function", stateMutability: "view", inputs: [{ name: "tokenId", type: "uint256" }], outputs: [{ type: "string" }], }, ], functionName: "tokenURI", args: [1n], });

A partir daí, as peças se mapeiam para infraestrutura que você provavelmente já opera. Webhooks transformam novos registros e eventos de feedback em envios em vez de polling, e como organizar o ciclo em torno desses eventos é abordado em nosso guia de arquiteturas de agentes de IA onchain. A carteira operacional do agente deve ser um signer escopado em vez de uma chave crua, o padrão que nosso guia de agentes onchain percorre do início ao fim. E o agente pode conduzir sozinho, de forma autônoma, seu próprio relacionamento com a infraestrutura, já que agentes podem se cadastrar em nossa plataforma usando uma carteira como identidade e pagar por chamada via x402, sem humano no ciclo. Se você constrói a partir de um agente de código, o plugin Alchemy para Claude Code empacota nosso servidor MCP e nossas skills em uma única instalação.

Tudo o que um agente ERC-8004 faz a jusante do registry, ler estado da chain, observar eventos, assinar transações e pagar pelo próprio uso da API, roda sobre infraestrutura que construímos para agentes como usuários de primeira classe. Obtenha um endpoint gratuito pela Alchemy CLI, ou deixe seu agente se cadastrar sozinho. Sem entrega manual de API key, sem contrato, e nada no ciclo de cadastro que exija um humano.

Quais são as limitações do ERC-8004?

O padrão é jovem, e suas arestas mais afiadas estão documentadas em sua própria thread de discussão. As que devem moldar seu design:

  • Feedback sybil é barato. Carteiras não custam nada, então pontuações brutas de reputação são facilmente fabricadas. Consuma feedback filtrado por clientes conhecidos ou provas de pagamento, nunca médias sem filtro.
  • A identidade é transferível. Uma identidade de agente é um ERC-721 padrão, então uma identidade antiga com histórico limpo pode ser vendida, e sua reputação vai junto. Rastreie mudanças de propriedade antes de confiar no histórico.
  • As pontuações envelhecem mal. Agentes são estocásticos, e uma atualização de modelo pode mudar o comportamento da noite para o dia, então o feedback do mês passado descreve o agente do mês passado.
  • A reputação fica em uma única chain. Um agente registrado na Base começa do zero na Arbitrum. A agregação cross-chain é um problema de indexador que o padrão ainda não resolve.
  • As interfaces ainda podem mudar. O padrão continua em rascunho e já foi redesenhado uma vez. Fixe sua integração aos contratos implantados, e acompanhe a especificação antes de depender de superfícies mais novas.

Nada disso invalida a afirmação real do padrão, que nunca foi a de que a reputação onchain é infalsificável. A afirmação é que sinais de confiança de agentes pertencem a um schema público, compartilhado e sem permissão, em vez de espalhados por bancos de dados privados. Julgado por essa afirmação, ele está ativo e já está sendo lido por sistemas reais.

Perguntas frequentes

O que é ERC-8004 e como ele viabiliza agentes de IA trustless?

ERC-8004 é um padrão Ethereum que registra agentes de IA onchain por meio de três registries que cobrem identidade, reputação e validação. Os agentes recebem uma identidade portátil e verificável como um token ERC-721, os clientes postam feedback publicamente, e os validadores atestam a qualidade do trabalho, para que os agentes possam transacionar entre organizações sem confiança pré-existente.

O ERC-8004 está ativo na mainnet?

Sim. Os registries de Identity e Reputation rodam na mainnet da Ethereum desde janeiro de 2026 e estão implantados nos mesmos endereços em mais de vinte redes.

O ERC-8004 tem um token?

Não. ERC-8004 é um padrão de smart contract, não um projeto com token. Registrar um agente cunha um token de identidade ERC-721 específico daquele agente, mas não há nenhum ativo fungível ERC-8004, e qualquer coisa comercializada como tal não tem relação com o padrão.

A identidade de um agente ERC-8004 pode ser vendida?

Sim. As identidades de agentes são tokens ERC-721 padrão, então são transferidas como qualquer NFT, e a reputação acumulada viaja junto com o token. Isso faz do histórico de propriedade parte da due diligence, já que uma reputação limpa pode ter sido comprada em vez de conquistada pelo operador atual.

Quais chains suportam o ERC-8004?

Os registries oficiais estão implantados em endereços idênticos em mais de vinte redes EVM, incluindo Ethereum, Base, Arbitrum, Optimism, Polygon, BSC e Monad. A Alchemy fornece RPC e APIs de dados nessas chains, para que os agentes possam ler e escrever nos registries onde quer que estejam implantados.

Em que o ERC-8004 é diferente do x402 e do A2A?

Eles resolvem camadas diferentes da mesma stack. O A2A cuida de como os agentes se encontram e trocam mensagens entre si, o x402 cuida de como eles pagam uns aos outros via HTTP, e o ERC-8004 cuida de se eles devem confiar uns nos outros, ancorando registros de identidade, reputação e validação onchain. Sistemas de agentes em produção normalmente combinam os três.

Background gradient

Construa magia blockchain

A Alchemy combina os produtos e ferramentas de desenvolvimento Web3 mais poderosos com recursos, comunidade e suporte lendário.