---
title: "O que é ERC-8004? Como os trustless agents funcionam na Ethereum"
description: "ERC-8004 é o padrão de trustless agents da Ethereum. Saiba como seus registros onchain de identidade, reputação e validação permitem que agentes de IA transacionem com segurança."
---

# O que é ERC-8004? Como os trustless agents funcionam na Ethereum

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-hero.png"
  alt="Imagem de capa do guia de trustless agents ERC-8004"
  width={1920}
  height={900}
  priority
/>

ERC-8004, intitulado Trustless Agents, é um padrão da Ethereum que dá aos 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 cobre como seus três registros funcionam, o que está de fato implantado na mainnet hoje, como o padrão se encaixa com [A2A](https://github.com/a2aproject/A2A), MCP e [x402](https://www.alchemy.com/blog/how-x402-brings-real-time-crypto-payments-to-the-web), e o que observar antes de construir sobre ele.

## O que é ERC-8004?

O [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) foi proposto em agosto de 2025 por autores da MetaMask, da Ethereum Foundation, do Google e da Coinbase, e define três registros. O Identity Registry (registro de identidade) registra quem um agente é. O Reputation Registry (registro de reputação) registra o que seus clientes dizem sobre ele. O Validation Registry (registro de validação) registra se validadores independentes checaram seu trabalho.

A spec é explícita em dizer que confiança não é uma coisa única. Em suas próprias palavras, os modelos de confiança são "plugáveis e escalonados, com segurança proporcional ao valor em risco, de tarefas de baixo risco como pedir uma pizza a tarefas de alto risco como um diagnóstico médico." Um agente reservando um jantar pode se apoiar em notas de reputação. Um agente gerenciando uma tesouraria precisa ter seu trabalho reverificado por alguém com dinheiro em jogo.

## 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 empresa. Chargebacks existem porque uma rede de cartões fica entre comprador e vendedor. Logins OAuth funcionam porque um grande provedor de identidade responde por você. Esse modelo quebra para agentes autônomos, que são feitos para operar entre empresas, nuvens e jurisdições sem um operador compartilhado.

O resto da stack de agentes se formou em torno dessa lacuna. O [Model Context Protocol](https://modelcontextprotocol.io/) (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 eles [paguem por serviços](https://www.alchemy.com/overviews/what-are-agent-payments) sobre HTTP simples. Cada um deles pressupõe que você já decidiu com qual contraparte trabalhar. Nenhum deles ajuda a tomar essa decisão.

Esse é o trabalho que o ERC-8004 assume, e é por isso que os registros vivem em uma blockchain, e não no banco de dados de alguém. Um [agente DeFi](https://www.alchemy.com/overviews/defi-ai-agents) escolhendo um venue de execução, um agente de pesquisa contratando um agente de rotulagem de dados e um merchant decidindo se atende um comprador desconhecido precisam das mesmas três consultas. Quem é esse agente? O que aconteceu quando outros trabalharam com ele? Alguém verificou seu output? O ERC-8004 coloca essas respostas em um lugar que nenhuma parte controla sozinha, em um único schema que todo agente consegue ler.

## Como funciona o Identity Registry do ERC-8004?

Cada agente registrado é um [token ERC-721](https://www.alchemy.com/blog/comparing-erc-721-to-erc-1155), o mesmo padrão por trás dos NFTs. Registrar chama `register()` no Identity Registry e faz o mint de um token cujo ID se torna o número do agente. O identificador completo do agente combina a chain e o endereço do registro com esse ID, então "agente 4.205 na Base" é globalmente inequívoco.

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 enxuto se parece com isto:

<CodeSnippet
  language="json"
  code={`{
  "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 todos os protocolos que ele fala, incluindo A2A, MCP, nomes ENS e identificadores descentralizados. O campo `supportedTrust` declara em quais modelos de confiança o agente opta por participar. A spec observa que, se ele 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, wallets e marketplaces já renderizam os tokens, e o tooling do ecossistema se aplica sem mudanças. O registro também separa a identidade das chaves que agem no dia a dia. `setAgentWallet` vincula uma wallet operacional ao agente com uma autorização assinada, então o dono do token de identidade e a wallet que assina transações podem ser chaves diferentes, com raios de dano diferentes. É a mesma separação que recomendamos ao [dar uma wallet a um agente](https://www.alchemy.com/blog/agent-wallets-alchemy-cli) desde o início, em que o agente recebe acesso de assinatura delimitado e com prazo, 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 com sinal e casas decimais configuráveis, então as notas podem ser negativas e precisas em vez de um grosseiro um-a-cinco, mais até duas tags para filtragem e um URI opcional apontando para um relato offchain mais rico, comprometido 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 escolhas de design importam mais do que as assinaturas das funções. Primeiro, clientes nunca se registram em lugar nenhum, o que mantém em zero a barreira para deixar feedback e permite que serviços [patrocinem o gas](https://www.alchemy.com/gasless-transactions) das avaliações de seus usuários. Segundo, o registro deliberadamente não computa nenhuma nota canônica. Ele armazena sinais brutos, oferece funções de resumo e leitura, e deixa a interpretação para quem o consulta. A discussão da proposta argumentou desde cedo que um único número agregado de reputação convida a dinâmicas de monopólio e a manipulação, então a pontuação vive na camada de indexação, onde consumidores diferentes podem pesar os mesmos dados de formas diferentes.

O arquivo de feedback offchain é onde as avaliações ganham força. Ele pode referenciar as ferramentas MCP ou tarefas A2A exatas que a interação usou, e pode embutir a prova de um pagamento x402, amarrando 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 nota solta de uma wallet anônima, e filtrar exatamente por esse tipo de avaliação é como se espera que consumidores sérios do registro o usem.

## Como funciona o Validation Registry do ERC-8004?

Notas de feedback dizem o que clientes passados acharam. Para trabalhos de maior valor, isso não basta, e o próprio output precisa ser checado. O Validation Registry permite que um agente solicite que um validador nomeado cheque um trabalho específico: `validationRequest` registra o validador, o agente e um ponteiro para o trabalho comprometido por hash, e o validador responde com `validationResponse`, pontuando o resultado de 0 a 100 com sua própria evidência comprometida por hash.

O que "checar" significa depende do validador. Ele pode reexecutar a tarefa e comparar os outputs, com stake que perde se atestar desonestamente. Pode atestar que o agente rodou dentro de um trusted execution environment (um TEE, hardware capaz de provar qual código executou). Pode verificar uma prova de machine learning de conhecimento zero (zkML, uma prova criptográfica de que um modelo específico produziu um output específico). O registro não se importa com qual; ele padroniza o encanamento de requisição e resposta.

Uma ressalva sobre o estado atual que quase nenhuma cobertura menciona. O deployment multi-chain oficial inclui os registros 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. Equipes que precisam de validação agora a conectam através de provedores específicos, como a [integração de trustless agents da EigenCloud](https://docs.eigencloud.xyz/products/eigenai/howto/build-trustless-agents), que combina a identidade ERC-8004 com sua própria computação verificável. Confira o [repositório oficial de contratos](https://github.com/erc-8004/erc-8004-contracts) para saber em que pé está o deployment antes de construir contra ele.

## Qual modelo de confiança um agente deve usar?

O enquadramento de valor em risco da spec vira uma regra de decisão bastante limpa. Iguale o custo da verificação ao custo de estar errado.

<EmbeddedTable
  table={{
    columns: [
      {
        key: "model",
        width: 200,
        title: "Modelo de confiança",
        dataType: "object",
      },
      { key: "how", width: 320, title: "Como funciona", dataType: "object" },
      { key: "fits", width: 260, title: "Indicado para", dataType: "object" },
    ],
    data: [
      {
        model: { title: "Reputação", tooltip: "", icon: "" },
        how: {
          title:
            "Clientes publicam feedback assinado onchain após cada interação",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "Tarefas de baixo risco e alto volume",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        model: { title: "Validação cripto-econômica", tooltip: "", icon: "" },
        how: {
          title:
            "Validadores com stake reexecutam o trabalho e perdem o stake por atestações falsas",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "Tarefas de maior valor com outputs checáveis",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        model: { title: "Atestação TEE", tooltip: "", icon: "" },
        how: {
          title: "O hardware prova qual código o agente de fato executou",
          tooltip: "",
          icon: "",
        },
        fits: {
          title:
            "Tarefas em que a integridade do processo importa, como o manuseio de chaves",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        model: { title: "Provas zkML", tooltip: "", icon: "" },
        how: {
          title:
            "Uma prova criptográfica de que um modelo específico produziu o output",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "Máxima garantia, atualmente a mais cara",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

Os modelos também se empilham. Um agente em produção pode rodar em um TEE, carregar um histórico de reputação e submeter outputs de alto valor para reexecução com stake, apresentando os três sinais através da mesma declaração `supportedTrust`.

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

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-agent-stack.png"
  alt="A stack de agentes: MCP, A2A e x402 com o ERC-8004 como camada de confiança onchain"
  width={1600}
  height={900}
/>

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, move o dinheiro, um entre [vários protocolos concorrentes de pagamento entre agentes](https://www.alchemy.com/overviews/x402-vs-mpp-comparing-agent-payment-protocols). 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 ele precisa, busca o arquivo de registro de um candidato e checa 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. Paga a fatura x402 que o vendedor retorna. Quando o trabalho termina, chama `giveFeedback` com uma referência ao pagamento, e o próximo cliente em potencial do vendedor vê uma avaliação com recibo anexado.

Nada na stack exige o loop completo. Equipes adotam x402 sem ERC-8004, e registram identidades sem nunca solicitar validação. Mas as camadas foram projetadas para referenciar umas às outras. O arquivo de registro lista endpoints A2A e MCP, e arquivos de feedback embutem recibos x402, então compô-las exige configuração em vez de código de cola.

## Como construir sobre o ERC-8004?

Ler os registros não exige tooling especial, porque eles são contratos comuns. Consultas de identidade são chamadas ERC-721, e todo registro emite eventos que você pode indexar. Atendemos todas as principais chains de deployment, então um endpoint RPC padrão basta para começar. Buscar o arquivo de registro de um agente leva uma única leitura:

<CodeSnippet
  language="typescript"
  code={`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 mapeiam para infraestrutura que você provavelmente já roda. [Webhooks](https://www.alchemy.com/webhooks) transformam novos registros e eventos de feedback em pushes em vez de polling, e a forma de organizar o loop em torno desses eventos está coberta no nosso [guia de arquiteturas de agentes de IA onchain](https://www.alchemy.com/overviews/onchain-ai-agent-architectures). A wallet operacional do agente deve ser um signer delimitado em vez de uma chave crua, o padrão que nosso [guia de agentes onchain](https://www.alchemy.com/blog/how-to-build-onchain-agents) percorre de ponta a ponta. E o agente pode gerenciar sua própria relação de infraestrutura de forma autônoma, já que [agentes podem se cadastrar na nossa plataforma](https://www.alchemy.com/blog/ai-agents-can-now-sign-up-for-alchemy) com uma wallet como identidade e pagar por chamada via x402, sem humano no loop. Se você constrói a partir de um agente de codificação, o [plugin da Alchemy para Claude Code](https://www.alchemy.com/blog/alchemy-claude-plugin-now-live) reúne nosso servidor MCP e skills em uma única instalação.

Tudo o que um agente ERC-8004 faz depois do registro, ler estado da chain, observar eventos, assinar transações e pagar pelo próprio uso de API, roda sobre infraestrutura que construímos para agentes como usuários de primeira classe. Pegue um endpoint gratuito pelo [Alchemy CLI](https://www.alchemy.com/agents), ou deixe seu agente se cadastrar sozinho. Sem repasse de API key, sem contrato, e nada no loop de cadastro que precise de um humano.

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

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

- **Feedback Sybil é barato.** Wallets não custam nada, então notas de reputação brutas são fabricadas com facilidade. 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.
- **Notas 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. 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 um draft e já foi redesenhado uma vez. Fixe sua integração nos contratos implantados, e acompanhe a spec antes de depender de superfícies mais novas.

Nenhum desses pontos quebra a alegação real do padrão, que nunca foi a de que reputação onchain é infalsificável. A alegação é que sinais de confiança de agentes pertencem a um schema público, compartilhado e permissionless, em vez de espalhados por bancos de dados privados. Julgado por essa alegação, o padrão está ativo e já é lido por sistemas reais.

## Perguntas frequentes

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

O ERC-8004 é um padrão da Ethereum que registra agentes de IA onchain através de três registros cobrindo identidade, reputação e validação. Agentes ganham uma identidade portátil e verificável como um token ERC-721, clientes publicam feedback publicamente e validadores atestam a qualidade do trabalho, então agentes podem transacionar entre organizações sem confiança pré-existente.

### O ERC-8004 está ativo na mainnet?

Sim. Os registros 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. O ERC-8004 é um padrão de smart contract, não um projeto com token. Registrar um agente faz o mint de um token de identidade ERC-721 específico daquele agente, mas não existe um ativo fungível ERC-8004, e qualquer coisa comercializada como tal não tem afiliação com o padrão.

### Uma identidade de agente ERC-8004 pode ser vendida?

Sim. Identidades de agente são tokens ERC-721 padrão, então elas se transferem como qualquer NFT, e a reputação acumulada viaja com o token. Isso torna o 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 ERC-8004?

Os registros 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, então agentes podem ler e escrever nos registros onde quer que estejam implantados.

### Como o ERC-8004 difere do x402 e do A2A?

Eles resolvem camadas diferentes da mesma stack. O A2A cuida de como agentes se encontram e trocam mensagens, o x402 cuida de como eles pagam uns aos outros sobre 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 tipicamente compõem os três.