Co-desenvolvido pelo Virtuals Protocol e pela equipe dAI da Ethereum Foundation
Especificação: https://eips.ethereum.org/EIPS/eip-8183
Discussão: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Participe da Comunidade de Builders: https://t.me/erc8183
Comércio: pré-requisito para IA descentralizada
Para que agentes de IA sejam acessíveis, descentralizados, sem controle de uma única plataforma, sem dependência de um único provedor e sem risco de um ponto único de falha, o comércio é indispensável. O comércio não pode ser relegado a segundo plano, mas sim considerado infraestrutura fundamental. E precisa ser sempre aberto e sem restrições. Este é o "espaço digital compartilhado sem proprietário" que @ethereum nasceu para criar.
Por quê? Porque descentralização na camada de IA e agentes exige muitos agentes e serviços independentes. Por exemplo: se apenas um agente gera imagens e deixa de operar, a geração de imagens é centralizada, independentemente do protocolo. Se apenas um provedor controla a execução de negociações, a gestão de fundos depende da disposição de uma única parte. E se apenas uma plataforma controla a infraestrutura de liquidação, todos os provedores e clientes ficam sujeitos às regras dessa plataforma, mesmo que haja mil agentes nela.
Isso exige comércio aberto: qualquer agente deve poder comprar um serviço, qualquer agente deve poder oferecer um serviço. Sem barreiras, sem jardins murados. Sem intermediário obrigatório.
Por que blockchain
O comércio só funciona quando todas as partes podem confiar que o acordo será cumprido. Se um cliente paga antecipadamente, como saber se o provedor irá entregar? Se um provedor entrega primeiro, como saber se o cliente irá pagar? Alguém precisa custodiar os fundos, acompanhar a realização do trabalho e garantir o resultado: liberar pagamento na conclusão, reembolsar em caso de falha. É a confiança (ou a falta dela) que fundamenta o surgimento de entidades centralizadas ou barreiras de entrada.
Na arquitetura tradicional, esse "alguém" é uma plataforma. Uma empresa detém o escrow, controla o state machine e decide quem recebe e quando. Isso funciona até deixar de funcionar. A plataforma pode mudar as regras, congelar fundos, remover provedores, encerrar operações. Todo participante depende do bom comportamento contínuo da plataforma. Isso é centralização, não no protocolo, mas na execução. Não é errado, mas necessário em um sistema sem confiança. O objetivo é a detotalização: impedir que qualquer entidade tenha controle total sobre como agentes transacionam. Vimos isso de perto: builders querem infraestrutura confiável sem depender do comportamento de uma única plataforma.
Um smart contract em uma cadeia descentralizada tenta resolver isso. O escrow, o state machine e a validação do avaliador vivem em código público, imutável e sem dono. O contrato é o executor neutro, gerando sinais relevantes para reputação das partes envolvidas.
A liquidação on-chain também produz algo que uma plataforma centralizada não pode: registros portáteis, verificáveis e imutáveis. Cada tarefa concluída, cada validação do avaliador, cada hash de entrega é registrado on-chain, visível para qualquer agente, em qualquer plataforma, por qualquer interface. Esses registros alimentam sistemas de reputação e identidade de agentes. Sem liquidação on-chain, não há histórico verificável. Sem histórico verificável, não há reputação portátil. Sem reputação portátil, cada interação entre agentes começa do zero em confiança.
Por isso, um padrão on-chain é necessário. O escrow, as transições de estado, a validação. Essas partes precisam ser neutras, seguras e executáveis.
Descoberta, negociação e comunicação podem acontecer on ou off-chain, pela interface mais natural. Um agente pode interagir via HTTP usando o protocolo x402, onde a experiência se assemelha a APIs ou requisições HTTPS padrão. O agente não precisa acessar a cadeia diretamente. Ele assina uma mensagem, e um facilitador cuida da liquidação on-chain e dos padrões. Ou agentes podem interagir diretamente via MCP ou A2A. A interface é flexível, mas a liquidação central deve ser trustless, programática e on-chain. Infraestrutura que sistemas centralizados não oferecem, pois isso enfraquece seu controle.
A economia dos agentes
Modelos de IA e agentes estão evoluindo rapidamente e se tornando mais capazes a cada mês. Tarefas que exigiam expertise humana há um ano, como escrever código de produção, gerar mídia profissional, analisar dados financeiros, coordenar fluxos complexos, agora são realizadas por agentes com qualidade igual ou superior. E a capacidade ainda está acelerando. A trajetória da IA torna a nova economia inevitável.
À medida que os agentes se tornam mais capazes, assumem trabalhos mais valiosos. Um agente que gera imagens indistinguíveis de fotografia profissional é um serviço pelo qual vale a pena pagar. Um agente que analisa um portfólio e executa negociações otimizadas está gerenciando dinheiro real. Um agente que revisa documentos jurídicos e identifica riscos realiza um trabalho que, feito por humanos, custa centenas de dólares por hora.
Esta é a transição-chave: IA e agentes estão se tornando participantes econômicos que geram valor e serviços.
E conforme a IA se torna universalmente acessível, todo indivíduo, organização ou dispositivo pode operar por meio de agentes. A economia então muda. Agentes não apenas interagem e atendem humanos; eles interagem e atendem uns aos outros. Por exemplo, um agente que coordena uma campanha contrata agentes de conteúdo, distribuição e análise. A economia se torna uma rede de agentes transacionando com agentes, em velocidade de máquina, em escala global.
Quando agentes são capazes de trabalhos valiosos e todos têm acesso a agentes, o resultado é uma economia onde a maioria das atividades comerciais flui por sistemas autônomos. É para isso que estamos construindo.
O problema: comércio trustless entre agentes
Uma economia de agentes exige comércio entre agentes. E o comércio entre agentes que nunca interagiram, que abrangem diferentes organizações e cadeias, precisa ser trustless.
Quando humanos transacionam, contratam ou utilizam um serviço, a confiança está no centro. Nesses casos, a confiança é mediada por plataformas, avaliações, sistemas jurídicos e normas sociais. Quando um agente contrata outro agente, nenhum desses mecanismos se aplica. Não há reputação social a consultar. Não há recurso jurídico ou reputacional que opere na velocidade das transações de máquina. Não há plataforma ou regulador estabelecendo a execução.
Então surge a questão: como tornar o comércio entre agentes trustless?
Não basta enviar dinheiro e esperar pelo melhor. Uma transferência de token não é comércio. É um pagamento sem garantias. Não há registro do que foi acordado. Não há mecanismo para custodiar fundos até que o trabalho seja satisfatório. Não há avaliação que produza sinais para outros agentes consultarem. Não há recurso se o provedor não entregar.
Há necessidade de engajamento estruturado: fundos mantidos em escrows descentralizados programáveis e imparciais, trabalho submetido como artefatos verificáveis, um avaliador que atesta se o entregável cumpre os termos e resultados determinísticos. Mecanismos que garantem a liberação de fundos na conclusão, reembolso em rejeição e recuperação se expirado. Tudo isso contribui para a identidade e reputação de todas as partes envolvidas.
ERC-8183: o Job primitivo
Em estreita colaboração com a equipe dAI da @ethereumfndn, formalizamos isso como um padrão. ERC-8183: Agentic Commerce, é um padrão aberto e sem permissões para aplicações de comércio entre agentes, com escrow e validação de avaliador programados como smart contracts on-chain.
ERC-8183 define um núcleo único: o Job. Cada Job envolve três partes: Cliente, Provedor e Avaliador. Cada parte é definida apenas pelo endereço de carteira, permitindo ampla aplicação e uso do primitivo.
Os principais componentes e princípios por trás do Job são: (i) especificação e descrição do job – um registro claro da tarefa, serviço ou trabalho vinculado ao pagamento; (ii) o pagamento em si – que é garantido em um escrow programado e imparcial até um estado final e liberado programaticamente; (iii) submissão registrada, verificável e rastreável do entregável protegendo cliente e provedor; e (iv) validação do avaliador, que resulta em sinais significativos para a identidade e reputação das partes – promovendo incentivos alinhados para liquidação trustless.
Isso motiva o fluxo do Job por quatro estados principais, garantindo transações trustless:
Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)
Em resumo, um Job é inicializado quando um Cliente cria um job com um Provedor e o financia, garantindo o pagamento em escrow. O Provedor realiza o trabalho e chama submit, colocando o entregável (ou uma referência dele) on-chain. Um Avaliador revisa a submissão e chama complete (liberando fundos ao provedor) ou reject (reembolsando o cliente). Se nem o provedor nem o avaliador agirem antes do prazo (tempo de expiração), o job expira e o cliente recupera seus fundos.
O padrão é deliberadamente minimalista e forma o primitivo atômico. Não especifica fluxos de negociação, estruturas de taxas, resolução de disputas, protocolos de comunicação ou mecanismos de descoberta. Especifica o ciclo de vida do job, a superfície mínima viável para comércio trustless entre agentes.
O avaliador
Um dos conceitos e decisões de design centrais no ERC-8183 é o conceito de Avaliador, definido apenas como um endereço. Sempre é um agente, no sentido mais amplo do termo.
Para tarefas subjetivas como redação, design ou análise, o avaliador pode ser um agente de IA que lê a submissão, compara com o pedido e faz um julgamento. Para tarefas determinísticas como computação, geração de provas ou transformação de dados, o avaliador é um smart contract envolvendo um verificador ZK. O provedor envia uma prova; o avaliador verifica on-chain e chama complete ou reject automaticamente. Para engajamentos de alto valor, o avaliador pode ser um multi-sig, uma DAO ou um validador respaldado por staking.
O padrão não distingue entre esses. Um endereço chama complete ou reject. Se esse endereço roda um agente com LLM ou um circuito ZK não é preocupação do protocolo. Isso permite que a mesma interface funcione para um job de geração de imagem de US$ 0,10 e um engajamento de gestão de fundos de US$ 100.000.
Hooks: extensibilidade modular
O Job primitivo é deliberadamente minimalista. Mas o comércio não é. Aplicações reais precisam de validação personalizada, atualização de reputação, distribuição de taxas, transferências de fundos, mecanismos de leilão e lógica específica de domínio que varia entre casos de uso. Um job de avaliação de conteúdo, uma troca de tokens e uma posição de mercado de previsão exigem lógicas fundamentalmente diferentes.
O ERC-8183 resolve isso com hooks. Um hook é um smart contract opcional anexado ao Job na criação. Ele recebe callbacks antes e depois de cada ação, permitindo lógica personalizada ao redor do ciclo de vida central sem modificá-lo. O hook é identificado por um único selector de função (qual transição está ocorrendo) e recebe os parâmetros relevantes. Pode impor pré-condições, bloquear ações inválidas, disparar efeitos colaterais ou executar transferências de tokens adicionais, tudo dentro da mesma transação da mudança de estado central.
Se nenhum hook for definido, o contrato executa normalmente. Uma implementação sem hook é totalmente compatível com o ERC-8183. Hooks são aditivos, não obrigatórios. Esse design mantém o contrato central pequeno e a interface estável. Novos casos de uso são suportados por novos hooks, mantendo a lógica de extensão on-chain, programática e trustless, igual ao núcleo.
Exemplos de aplicações de comércio
O Job central atende ao comércio de serviços direto: pagar, entregar, avaliar. Mas a economia em que agentes operam não é simples. Alguns jobs envolvem gerenciar o capital do cliente, não apenas receber uma taxa. Alguns precisam de precificação competitiva antes de um provedor ser designado. Alguns exigem verificações de confiança que consultam dados externos de reputação. São modelos econômicos fundamentalmente diferentes e os hooks permitem que a mesma interface do Job suporte essa diversidade, tornando o ERC-8183 um primitivo versátil de comércio.
-
Service Jobs são o padrão e não requerem hook. Um cliente paga por geração de conteúdo, análise de dados ou revisão de código. O fluxo de escrow e avaliação central cobre tudo.
-
Fund Transfer Jobs vão além de taxa de serviço. O cliente fornece capital (tokens para swap, fundos para investir), o provedor transforma e o output deve retornar. Um hook pode gerenciar esse fluxo de capital bidirecional junto ao escrow central, garantindo que o provedor deposite tokens de output antes de concluir o job. Isso abrange aplicações como yield farming, swaps de tokens, rebalanceamento de portfólio, qualquer job em que o provedor gerencia dinheiro do cliente ou exige capital inicial para executar, não apenas receber uma taxa.
-
Bidding Jobs alteram o modelo de atribuição. Em vez de o cliente escolher um provedor de início, provedores competem pelo preço. Um hook verifica bids assinadas criptograficamente no momento da atribuição, provando que o provedor selecionado se comprometeu com o preço. Nenhum lado pode fabricar ou negar os termos.
-
Reputation-Gated Jobs impõem confiança no nível do protocolo. Um hook consulta ERC-8004 antes de permitir ações, bloqueando provedores de baixa reputação ou exigindo termos mais rígidos para agentes não comprovados.
-
Privacy-Preserving Jobs usam hooks para permitir comércio sem exposição de dados. Em vez de publicar dados sensíveis on-chain, um Privacy Hook pode exigir que o campo 'Submission' contenha uma Zero-Knowledge Proof (ZKP) ou referência a um ambiente criptografado (como um TEE). Isso garante que o pagamento seja trustless e público, mas a propriedade intelectual ou dados pessoais permaneçam em 'santuário', acessíveis apenas aos agentes autorizados.
-
Risk-Assessed ou Underwriting Jobs podem impor underwriting no protocolo via hooks. Um hook pode exigir colateral de staking de provedores ou underwriters, verificar scores de reputação ERC-8004 e outros métricas relevantes antes da atribuição, impor bonds que são queimados em avaliações falhas ou consultar oráculos de risco externos. Processos de aprovação antes opacos tornam-se transparentes, programáveis e competitivos. Por exemplo, diferentes tolerâncias de risco podem ser atendidas; um servindo agentes estabelecidos com alta confiança pode exigir verificações mínimas, enquanto outro em domínios de alto risco pode exigir colateral significativo.
Cada uma dessas aplicações pode ser implementada como um contrato hook diferente, mantendo a funcionalidade central e o padrão do Job primitivo. Novos modelos econômicos, aplicações de comércio ou lógicas customizadas são novos hooks. Introduzimos alguns hooks iniciais para demonstrar o que é possível, mas acreditamos que apenas arranhamos a superfície e os hooks mais interessantes ainda não foram escritos. Como será o comércio entre agentes para seguros, colaboração criativa, coordenação de cadeia de suprimentos? Ainda não sabemos, e esse é o ponto. Além disso, o comércio entre agentes evoluirá de formas que ninguém pode antecipar plenamente: novos modelos econômicos, mecanismos de confiança e formas de colaboração entre máquinas. O padrão foi projetado para crescer com essa evolução, não para limitá-la. Esse padrão deve ser construído de forma aberta, porque as melhores ideias virão do ecossistema, e estamos ansiosos para descobri-las juntos.
ERC-8183 não existe isoladamente. Ele é simbiotico com o ERC-8004 ("Trustless Agents"), padrão Ethereum para identidade, reputação e validação de agentes.
ERC-8004 resolve descoberta e confiança: como agentes se encontram e avaliam confiabilidade. Mas seus registros só têm valor pelo que registram. Identidade sem comércio ou ações é um perfil vazio. Reputação exige interações reais para medir. Validação precisa de entregáveis definidos para verificar.
ERC-8183 fornece o comércio que alimenta a camada de confiança do ERC-8004. Cada job é um sinal de reputação. Cada submissão é um entregável que validadores podem avaliar. Cada avaliação é uma validação que outros agentes podem consultar.
Os dois padrões formam um ciclo que potencialmente permite maior auto-organização entre agentes por interações trustless:
Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce
Nenhum é completo sem o outro. Juntos, formam a base do comércio e interação trustless entre agentes.
Além de pagamentos
ERC-8183 não é um protocolo de pagamentos. É um padrão de comércio.
Um pagamento move dinheiro. Mas comércio exige mais do que mover dinheiro. Comércio é tudo ao redor do pagamento que o torna confiável e funcional: o que foi acordado, se o trabalho foi feito, quem verificou e o que acontece se não foi. No mundo tradicional, o comércio funciona por causa do que envolve o pagamento: avaliação de risco e underwriting de comerciantes antes de aceitarem pagamentos, extensão de crédito para compradores transacionarem antes que fundos estejam disponíveis, detecção de fraude em bilhões de transações em tempo real, mecanismos de chargeback e disputas que protegem compradores quando serviços falham e sistemas de reputação que acumulam confiança em interações repetidas. Essas funções tornam processadores de pagamentos, redes de cartões e plataformas valiosas; não o movimento de fundos em si, mas a infraestrutura de confiança ao redor.
Quando o comércio migra para on-chain, essas funções não desaparecem. Precisam ser reconstruídas de forma trustless, programática e aberta. É isso que o ERC-8183 oferece.
O modelo de escrow e validação do Job primitivo é análogo a mecanismos de chargeback com termos de liquidação programáveis e antecipados. Usar reputação on-chain do ERC-8004 e outros históricos e métricas on-chain como parte do ERC-8183 é análogo ao underwriting proprietário com histórico portátil e verificável.
Hooks substituem avaliação de risco centralizada por lógica modular, competitiva e auditável que qualquer facilitador pode implantar. O resultado não é apenas uma forma de mover dinheiro on-chain, mas de reconstruir toda a infraestrutura de confiança do comércio, de modo aberto e sem permissões.
Protocolos e interfaces de pagamento existentes, seja processadores tradicionais ou protocolos de transferência de stablecoin como x402, são experiências nativas da internet que lidam com o movimento de fundos. O ERC-8183 gerencia o ciclo completo que transforma um pagamento em uma transação trustless: especificação, escrow, submissão do entregável, validação do avaliador e liquidação determinística. Um agente pode interagir via x402 ou HTTP na camada de interface enquanto a liquidação subjacente ocorre via ERC-8183 on-chain. São complementares.
Irreversibilidade, escrow e o problema do chargeback
Outra preocupação com pagamentos isolados é a irreversibilidade. Quando um cartão é cobrado e o serviço é insatisfatório, o consumidor contesta e reverte a cobrança. Quando um pagamento é transferido, o dinheiro se foi. Essa é uma objeção real e válida para pagamentos e transferências brutas.
ERC-8183 mantém esse conceito central em sua estrutura contratual. Fundos ficam em escrow até que um avaliador ateste que o entregável cumpre os termos acordados. O caminho de rejeição reembolsa o cliente. O caminho de expiração auto-recupera. É um equivalente programável e trustless ao modelo de autorização e captura que faz o comércio com cartão funcionar, exceto que os termos são codificados antecipadamente e executados por código, não julgados depois por uma rede com seus próprios incentivos.
Para pré-autorizações de valores incertos, como bloqueio de hotel ou serviço com escopo variável, a flexibilidade dos hooks pode ser projetada para bloquear um valor máximo e liquidar um valor final determinado por inputs verificáveis na conclusão. A arquitetura suporta padrões que tornam os comportamentos de confiança do comércio com cartão flexíveis, mantendo a liquidação transparente, aberta, trustless e on-chain.
A nova onda de participantes econômicos
A onda da IA está criando novos participantes econômicos, compradores e comerciantes, mais rápido do que qualquer mudança anterior. Milhões de desenvolvedores e não desenvolvedores estão construindo e lançando micro-serviços, APIs e ferramentas usando assistentes de código IA, muitos sem entidade legal, site ou histórico de transações. Agentes de empresas de tecnologia e frameworks de código aberto estão trazendo milhões de usuários com agentes pessoais de IA e assistentes.
Sistemas tradicionais de pagamento terão dificuldade em atender esses comerciantes. Não por falta de tecnologia, mas porque quando um processador aprova um Provedor, absorve o risco desse provedor: fraude, chargebacks, disputas. Um comerciante sem histórico, sem entidade e sem passado é arriscado demais para underwriting.
ERC-8183 é permissionless por design. Um provedor é um endereço de carteira. Sem onboarding, sem underwriting, sem gatekeeper. O Job primitivo dá a esses comerciantes não apenas uma forma de receber, mas um ciclo completo de comércio: especificação do trabalho, pagamento em escrow, submissão verificável do entregável e validação do avaliador, fornecendo a base de uma transação confiável.
A incapacidade de fazer underwriting de novos provedores pode ser vista como uma lacuna temporária. Um padrão aberto comprime esse tempo estruturalmente. Qualquer facilitador pode implantar o ERC-8183 hoje. O ecossistema evolui por experimentação, não por consenso institucional. Mas, mais fundamentalmente, ERC-8183 combinado com ERC-8004 não apenas preenche a lacuna de underwriting, resolve a causa raiz. O motivo pelo qual processadores não podem fazer underwriting de novos comerciantes é a ausência de histórico verificável. ERC-8183 produz esse histórico. Cada job concluído é registrado on-chain: hash do entregável, validação do avaliador, resultado. Esse histórico é portátil, verificável e não pertence a ninguém.
Importante, o histórico não fica preso em uma única plataforma. Hoje, a plataforma A conhece sua taxa de chargeback, a plataforma B conhece sua pontuação de vendedor, mas você não pode levar esse histórico para outro lugar. No ERC-8183, reputação é o ativo portátil do comerciante, lido por qualquer facilitador, em qualquer cadeia, por qualquer interface que leia o padrão. ERC-8183 alimenta identidade e reputação on-chain (ERC-8004) e fornece dados para underwriting.
Construindo juntos o futuro do comércio entre agentes e IA descentralizada
ERC-8183 é um padrão aberto para comércio trustless entre agentes. Veja como participar:
Construa com ERC-8183. Seja um facilitador! Implante ERC-8183 em sua cadeia. Construa SDKs. Construa wrappers. Construa scanners e trackers. Crie novas interfaces e experiências, e permita que elas liquidem de forma segura e verificável on-chain com ERC-8183. Crie frameworks de agentes que interajam nativamente com o padrão.
Explore, experimente e construa hooks. Precisa de pagamentos por marcos ou resolução de disputas? Construa como hooks. Este é o espaço para criatividade e evolução para uma ampla diversidade de aplicações.
Construa e registre avaliadores. Avaliadores são parte fundamental para garantir comércio trustless entre agentes, mas ainda são escassos. Construa avaliadores para domínios específicos, especialmente para domínios e serviços totalmente verificáveis. Registre-os no ERC-8004. Contribua significativamente para reputação e identidade de agentes.
Contribua e dê feedback. Este é um padrão coletivo. Só será o que precisa ser por ampla experimentação, uso real, feedback honesto e iteração. Se algo falta, proponha. Se algo está errado, questione. A especificação é aberta, o repositório é aberto, a discussão é aberta. Isso evolui junto.
A economia dos agentes será construída sobre padrões abertos ou sobre jardins murados. Escolhemos padrões abertos. Um espaço digital compartilhado.
ERC-8004 para confiança. ERC-8183 para comércio. Todo o resto é seu para construir.
Quer saber mais?
Especificação ERC-8183: https://eips.ethereum.org/EIPS/eip-8183
Especificação ERC-8004: eips.ethereum.org/EIPS/eip-8004
Discussão ERC-8183: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Participe da Comunidade no Telegram: https://t.me/erc8183
Isenção de responsabilidade:
-
Este artigo foi republicado de [virtuals_io]. Todos os direitos autorais pertencem ao autor original [virtuals_io]. Caso haja objeções a esta republicação, entre em contato com a equipe Gate Learn, que irá tratar da questão prontamente.
-
Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem aconselhamento de investimento.
-
As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Exceto quando mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.
