Co-desenvolvido pelo Virtuals Protocol e pela equipa dAI da Ethereum Foundation
Especificação: https://eips.ethereum.org/EIPS/eip-8183
Discussão: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Junte-se à Comunidade de Builders: https://t.me/erc8183
Comércio: pré-requisito para a IA descentralizada
Se o objetivo é que agentes de IA sejam verdadeiramente acessíveis, descentralizados, não sujeitos ao controlo de uma única plataforma, não dependentes de um só fornecedor e imunes a pontos únicos de falha, o comércio é absolutamente essencial. O comércio não pode ser um elemento secundário; é a infraestrutura de base. E esse comércio deve ser sempre aberto e sem permissões. Este é o “espaço digital partilhado sem proprietário” que @ethereum foi criado para concretizar.
Porquê? Porque a descentralização ao nível da IA e dos agentes exige múltiplos agentes e serviços independentes. Por exemplo, se apenas um agente conseguir gerar imagens e deixar de o fazer, a geração de imagens fica centralizada, independentemente do protocolo em causa. Se apenas um fornecedor controlar a execução de ordens, a gestão de fundos depende da vontade de uma única parte. E se só uma plataforma controlar a infraestrutura de liquidação, todos os fornecedores e clientes ficam sujeitos às regras dessa plataforma, mesmo que nela existam mil agentes.
Isto exige comércio aberto: qualquer agente pode adquirir um serviço, qualquer agente pode oferecer um serviço. Sem gatekeeping, sem jardins murados. Sem intermediários obrigatórios.
Porquê blockchain
No entanto, de forma crítica, o comércio só funciona quando todas as partes podem confiar que o acordo será cumprido. Se um cliente paga antecipadamente, como pode saber que o fornecedor irá entregar? Se o fornecedor entrega primeiro, como pode saber que o cliente irá pagar? Alguém tem de reter os fundos, verificar se o trabalho foi feito e garantir o resultado: libertar o pagamento na conclusão, reembolsar em caso de falha. É a confiança (ou a falta dela) que, no fundo, dá origem a entidades centralizadas e gatekeeping.
Na arquitetura tradicional, esse alguém é uma plataforma. Uma empresa que detém o escrow, controla a máquina de estados e decide quem recebe e quando. Isto funciona até deixar de funcionar. A plataforma pode mudar as regras. Pode congelar fundos. Pode remover fornecedores. Pode encerrar a atividade. Cada participante depende do bom comportamento da plataforma. Isto é centralização, não ao nível do protocolo, mas da execução. Não é errado, mas é necessário num sistema sem confiança. O objetivo é a des-totalização: evitar que qualquer entidade detenha controlo total sobre a forma como agentes transacionam. Já vivemos isto: os builders querem infraestrutura fiável sem depender do bom comportamento de uma plataforma.
Um smart contract numa blockchain descentralizada tenta resolver este problema. O escrow, a máquina de estados e a validação do avaliador vivem em código público, imutável e sem proprietário. O contrato é o executor neutro, originando sinais relevantes para a reputação das partes envolvidas.
A liquidação on-chain gera ainda algo que uma plataforma centralizada não consegue: registos portáteis, verificáveis e imutáveis. Cada trabalho concluído, cada validação do avaliador, cada hash de entrega é registado on-chain, visível para qualquer agente, em qualquer plataforma, por qualquer interface. Estes registos alimentam sistemas de reputação e identidade dos 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 termos de confiança.
É por isso que é necessário um standard onchain. O escrow, as transições de estado, a validação. Estas componentes têm de ser neutras, seguras e executáveis.
A descoberta, negociação e comunicação podem acontecer on-chain ou off-chain, pela interface mais natural. Um agente pode interagir via HTTP usando o protocolo x402, onde a experiência é idêntica a APIs ou pedidos HTTPS padrão. O agente não precisa de interagir diretamente com a cadeia. Assina uma única mensagem e um facilitador trata da liquidação on-chain e dos standards. 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. É uma infraestrutura que sistemas centralizados não fornecerão, porque isso mina o seu controlo.
A economia dos agentes
Os modelos e agentes de IA estão a evoluir rapidamente e a tornar-se mais capazes mês após mês. Tarefas que há um ano exigiam perícia humana – escrever código de produção, gerar conteúdos profissionais, analisar dados financeiros, coordenar fluxos de trabalho complexos – são agora executadas por agentes com qualidade comparável ou superior. E a capacidade continua a acelerar. A trajetória da IA torna inevitável a nova economia.
À medida que os agentes se tornam mais capazes, assumem trabalhos de maior valor. Um agente que gera imagens indistinguíveis de fotografia profissional é um serviço que justifica pagamento. Um agente que analisa uma carteira e executa ordens otimizadas está a gerir dinheiro real. Um agente que revê documentos legais e assinala riscos faz um trabalho que, se feito por humanos, custa centenas de dólares por hora.
Esta é a transição-chave: IA e agentes tornam-se participantes económicos que geram valor e serviços.
E, à medida que a IA se torna universalmente acessível, cada indivíduo, organização ou dispositivo pode operar através de agentes. A economia muda. Os agentes não servem apenas humanos; interagem e prestam serviços entre si. Por exemplo, um agente que coordena uma campanha contrata agentes de conteúdos, de distribuição e de análise. A economia torna-se uma rede de agentes a transacionar com agentes, à velocidade da máquina e à escala global.
Quando os agentes são capazes de trabalho valioso e todos têm acesso a agentes, o resultado é uma economia onde a maioria da atividade comercial flui através de sistemas autónomos. É para isto que estamos a construir.
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, abrangendo diferentes organizações e cadeias, tem de ser trustless.
Quando humanos transacionam, contratam outros humanos ou um serviço, a confiança está no centro. Nestes casos, a confiança é mediada por plataformas, avaliações, sistemas jurídicos e normas sociais. Quando um agente contrata outro agente, nenhum destes mecanismos se aplica. Não existe reputação social a consultar. Não há recurso jurídico ou reputacional que opere à velocidade das transações entre máquinas. Não existe plataforma ou regulador a garantir a execução.
Portanto, a questão é: como tornar o comércio entre agentes trustless?
Não pode simplesmente enviar dinheiro e esperar o melhor. Uma transferência de tokens não é comércio. É um pagamento sem garantias. Não há registo do que foi acordado. Não existe mecanismo para reter fundos até que o trabalho esteja satisfatório. Não há avaliação que produza sinais que outros agentes possam consultar. Não há recurso se o fornecedor não entregar.
É preciso um envolvimento estruturado: fundos retidos em escrows descentralizados programáveis e imparciais, trabalho submetido como artefactos verificáveis, um avaliador que atesta se a entrega cumpre os termos e desfechos determinísticos. Mecanismos que garantem que os fundos são libertados na conclusão, reembolsados em caso de rejeição e recuperáveis se expirarem. Tudo isto contribui para a identidade e reputação das partes envolvidas.
ERC-8183: o primitivo de Trabalho
Em estreita colaboração com a equipa dAI da @ethereumfndn, formalizámos isto como um standard. ERC-8183: Agentic Commerce é um standard aberto e sem permissões para aplicações de comércio entre agentes, com escrow e validação do avaliador programados como smart contracts onchain.
O ERC-8183 define um único núcleo: o Trabalho (Job). Cada Trabalho envolve três partes: o Cliente, o Fornecedor e o Avaliador. Cada parte é definida apenas pelo seu endereço de carteira, permitindo a ampla aplicação e utilização do primitivo.
Os principais componentes e princípios do primitivo de Trabalho são: (i) especificação e descrição do trabalho – um registo claro da tarefa, serviço ou trabalho associado ao pagamento; (ii) o próprio pagamento – garantido num escrow programado e imparcial até um estado terminal e libertado programaticamente; (iii) submissão registada, verificável e rastreável da entrega, protegendo cliente e fornecedor; e (iv) validação do avaliador, que resulta em sinais relevantes para a identidade e reputação das partes envolvidas – alinhando incentivos para liquidação trustless.
Isto motiva o fluxo do Trabalho por quatro estados-chave, garantindo transações trustless:
Aberto → Financiado → Submetido → Terminal (Concluído / Rejeitado / Expirado)
Em resumo, um Trabalho é criado quando um Cliente cria um trabalho com um Fornecedor e o financia, garantindo o pagamento em escrow. O Fornecedor executa o trabalho e submete, colocando a entrega (ou uma referência) on-chain. Um Avaliador revê a submissão e marca como concluído (libertando fundos para o fornecedor) ou rejeita (reembolsando o cliente). Se nem o fornecedor nem o avaliador atuarem antes do prazo (tempo de expiração), o trabalho expira e o cliente recupera os fundos.
O standard é deliberadamente minimalista e constitui 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 central do trabalho, o mínimo viável para comércio trustless entre agentes.
O Avaliador
Um dos conceitos e decisões de design fundamentais no ERC-8183 é o conceito de Avaliador, e o facto de o avaliador ser apenas um endereço. É sempre um agente, no sentido mais amplo do termo.
Para tarefas subjetivas como escrita, design ou análise, o avaliador pode ser um agente de IA que lê a submissão, compara com o pedido e decide. Para tarefas determinísticas como computação, geração de provas ou transformação de dados, o avaliador é um smart contract que integra um verificador ZK. O fornecedor submete uma prova; o avaliador verifica-a on-chain e marca como concluído ou rejeita automaticamente. Para envolvimentos de alto valor, o avaliador pode ser um multi-sig, uma DAO ou um validador suportado por staking.
O standard não distingue entre estes casos. Um endereço chama complete ou reject. Se esse endereço executa um agente com LLM ou um circuito ZK não é relevante para o protocolo. Isto permite que a mesma interface funcione tanto para um trabalho de geração de imagem de 0,10$ como para uma gestão de fundos de 100 000$.
Hooks: extensibilidade modular
O primitivo de Trabalho é deliberadamente minimalista. Mas o comércio não é. Aplicações reais exigem 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 do domínio, que varia consoante o caso. Um trabalho de avaliação de conteúdos, uma troca de tokens e uma posição num mercado de previsões requerem lógicas fundamentalmente diferentes.
O ERC-8183 resolve isto com hooks. Um hook é um smart contract opcional ligado a um Trabalho na criação. Recebe callbacks antes e depois de cada ação, permitindo executar lógica personalizada em torno do ciclo de vida central sem o modificar. O hook é identificado por um único function selector (qual transição está a ocorrer) e recebe os parâmetros relevantes. Pode impor pré-condições, bloquear ações inválidas, desencadear efeitos laterais ou executar transferências adicionais de tokens, tudo na mesma transação da alteração de estado principal.
Se não houver hook, o contrato executa normalmente. Uma implementação sem hook cumpre integralmente o ERC-8183. Os hooks são opcionais, não obrigatórios. Este 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, tal como o núcleo.
Exemplos de aplicações de comércio
O Trabalho central gere o comércio de serviços direto: pagar, entregar, avaliar. Mas a economia em que os agentes operam não é linear. Alguns trabalhos envolvem gerir capital do cliente e não apenas receber uma taxa. Alguns exigem preços competitivos antes de se atribuir um fornecedor. Outros requerem verificações de confiança baseadas em dados de reputação externos. Estes são modelos económicos fundamentalmente diferentes, e os hooks permitem que a mesma interface central do Trabalho suporte esta diversidade e tornem o ERC-8183 um primitivo de comércio versátil.
-
Trabalhos de Serviço são a base e não requerem hook. Um cliente paga pela geração de conteúdos, análise de dados ou revisão de código. O fluxo central de escrow e avaliação cobre tudo.
-
Trabalhos de Transferência de Fundos vão além de uma taxa de serviço. O cliente fornece capital (tokens para trocar, fundos para investir), o fornecedor transforma-o e o output tem de ser devolvido. Um hook pode gerir este fluxo bidirecional de capital juntamente com o escrow, garantindo que o fornecedor deposita tokens de output antes do trabalho ser concluído. Isto abrange aplicações como yield farming, trocas de tokens, reequilíbrio de carteiras, qualquer trabalho em que o fornecedor gere dinheiro do cliente ou que requeira capital inicial para executar e não apenas receber uma taxa.
-
Trabalhos de Licitação invertem o modelo de atribuição. Em vez de o cliente escolher o fornecedor à partida, os fornecedores competem no preço. Um hook verifica licitações assinadas criptograficamente no momento da atribuição, provando que o fornecedor selecionado se comprometeu com o preço. Nenhuma das partes pode fabricar ou negar os termos.
-
Trabalhos com Filtro de Reputação impõem confiança ao nível do protocolo. Um hook consulta o ERC-8004 antes de permitir ações, bloqueando fornecedores de baixa reputação ou exigindo termos mais rigorosos para agentes não comprovados.
-
Trabalhos com Preservação de Privacidade 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 uma referência a um ambiente encriptado (como um TEE). Assim, o pagamento é trustless e público, mas a propriedade intelectual ou dados pessoais permanecem protegidos, acessíveis apenas aos agentes autorizados.
-
Trabalhos Avaliados por Risco ou de Subscrição podem impor avaliação de risco ao nível do protocolo através de hooks. Um hook pode exigir colateral em staking de Fornecedores ou subscritores, consultar pontuações de reputação ERC-8004 e outros indicadores antes da atribuição, impor cauções que são penalizadas em avaliações negativas ou consultar oráculos de risco externos. Estes processos antes opacos tornam-se transparentes, programáveis e competitivos. Por exemplo, diferentes tolerâncias ao risco podem ser servidas; um para 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 destas aplicações pode ser implementada como um hook distinto, mantendo a funcionalidade central e o primitivo de Trabalho standard. Novos modelos económicos, aplicações de comércio ou variações de lógica personalizada são novos hooks. Apresentámos os primeiros hooks, exemplos para demonstrar o potencial, mas acreditamos que só arranhámos a superfície – os hooks mais interessantes ainda não foram criados. Como será o comércio entre agentes para seguros, colaboração criativa, coordenação de cadeias de abastecimento? Ainda não sabemos, e esse é o objetivo. O comércio entre agentes evoluirá de formas imprevisíveis, com novos modelos, mecanismos de confiança e formas de colaboração entre máquinas. O standard foi desenhado para crescer com essa evolução, não para a limitar. Este standard deve ser construído abertamente e merece sê-lo porque as melhores ideias virão do ecossistema, e queremos descobri-las em conjunto.
O ERC-8183 não existe isoladamente. É simbiótico com o ERC-8004 ("Trustless Agents"), o standard Ethereum para identidade, reputação e validação de agentes.
O ERC-8004 resolve descoberta e confiança: como agentes se encontram e avaliam fiabilidade. Mas os seus registos só têm valor pela atividade que registam. Identidade sem comércio ou ações é um perfil vazio. Reputação requer interações reais para ser medida. Validação precisa de entregas definidas para serem verificadas.
O ERC-8183 fornece o comércio que alimenta a camada de confiança do ERC-8004. Cada trabalho é um sinal de reputação. Cada submissão é uma entrega que validadores podem avaliar. Cada avaliação é uma validação que outros agentes podem consultar.
Os dois standards formam um ciclo que pode permitir maior auto-organização entre agentes através de interações trustless:
Descoberta (8004) → Comércio (8183) → Reputação (8004) → Melhor Descoberta → Mais Comércio Trustless
Nenhum está completo sem o outro. Juntos, formam a base do comércio e interação trustless entre agentes.
Para além dos pagamentos
O ERC-8183 não é um protocolo de pagamentos. É um standard de comércio.
Um pagamento move dinheiro. Mas comércio é mais do que transferir dinheiro. Comércio é tudo o que envolve o pagamento e o torna fiável e funcional: o que foi acordado, se o trabalho foi feito, quem o verificou e o que acontece se não foi. No mundo tradicional, o comércio funciona devido ao que rodeia o pagamento: avaliação de risco e subscrição de comerciantes antes de aceitarem pagamentos, concessão de crédito para compradores transacionarem antes de terem fundos, deteção de fraude em milhares de milhões de transações em tempo real, mecanismos de chargeback e resolução de disputas que protegem compradores quando os serviços falham e sistemas de reputação que acumulam confiança ao longo de interações repetidas. Estas funções tornam processadores de pagamentos, redes de cartões e plataformas valiosas; não pela movimentação de fundos em si, mas pela infraestrutura de confiança em seu redor.
Quando o comércio passa para on-chain, estas funções não desaparecem. Têm de ser reconstruídas de forma trustless, programática e aberta. É isso que o ERC-8183 faz.
O modelo de escrow e validação do avaliador do primitivo de Trabalho é análogo aos mecanismos de chargeback com termos de liquidação programáveis e definidos à partida. Usar reputação on-chain do ERC-8004 e outros indicadores históricos como parte do ERC-8183 é análogo à subscrição proprietária com histórico portátil e verificável.
Hooks substituem a avaliação de risco centralizada por lógica modular, competitiva e auditável que qualquer facilitador pode implementar. O resultado não é apenas uma forma de mover dinheiro on-chain, mas de reconstruir toda a infraestrutura de confiança do comércio, aberta e sem permissões.
Os protocolos e interfaces de pagamento existentes, sejam processadores tradicionais ou protocolos de transferência de stablecoin como x402, são experiências fluídas e nativas da internet que gerem a movimentação de fundos. O ERC-8183 gere o ciclo de vida completo que transforma um pagamento numa transação trustless: especificação, escrow, submissão da entrega, validação do avaliador e liquidação determinística. Um agente pode interagir por x402 ou HTTP na camada de interface enquanto a liquidação 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 é debitado e o serviço não é satisfatório, o consumidor contesta e reverte o débito. Quando um pagamento é transferido, o dinheiro desaparece. Isto é uma objeção real e válida para pagamentos e transferências simples.
O ERC-8183 mantém este conceito central na estrutura do contrato. Os fundos ficam em escrow até o avaliador atestar que a entrega cumpre os termos acordados. O caminho de rejeição reembolsa o cliente. O caminho de expiração permite recuperação automática. É o equivalente programável e trustless ao modelo de autorização e captura que faz o comércio com cartão funcionar, mas com termos definidos à partida e executados por código, não por uma rede com incentivos próprios.
Para pré-autorizações de montantes incertos, como uma caução de hotel ou um serviço cujo âmbito pode aumentar, a flexibilidade dos hooks permite bloquear um montante máximo e liquidar o valor final determinado por inputs verificáveis na conclusão. A arquitetura suporta os 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 vaga de participantes económicos
A vaga da IA está a criar novos participantes económicos, compradores e fornecedores, mais rápido do que qualquer mudança anterior. Milhões de developers e não-developers estão a criar e lançar micro-serviços, APIs e ferramentas com assistentes de código IA, muitos sem entidade legal, site ou histórico de transações. Agentes de empresas tecnológicas e frameworks open-source estão a trazer milhões de utilizadores com agentes e assistentes pessoais de IA.
Os sistemas de pagamento tradicionais terão dificuldades em servir estes fornecedores. Não por falta de tecnologia, mas porque, ao aprovar um Fornecedor, o processador absorve o risco desse fornecedor: fraude, chargebacks, disputas. Um comerciante sem histórico, sem entidade, sem registo é demasiado arriscado para subscrever.
O ERC-8183 é permissionless por design. Um fornecedor é um endereço de carteira. Sem onboarding, sem subscrição, sem gatekeeper. O primitivo de Trabalho oferece a estes fornecedores não apenas uma forma de receber pagamentos, mas todo o ciclo de comércio: especificação do trabalho, pagamento em escrow, submissão verificável da entrega e validação do avaliador, criando a base para uma transação fiável.
A incapacidade de subscrever novos fornecedores pode ser vista como uma lacuna temporária. Um standard aberto reduz este prazo estruturalmente. Qualquer facilitador pode implementar o ERC-8183 hoje. O ecossistema evolui por experimentação, não por consenso institucional. Mas, mais fundamentalmente, o ERC-8183 combinado com o ERC-8004 não só ultrapassa a lacuna da subscrição, como resolve a causa raiz. O motivo pelo qual processadores não subscrevem novos comerciantes é a ausência de histórico verificável. O ERC-8183 produz esse histórico. Cada trabalho concluído é registado on-chain: o hash da entrega, a validação do avaliador, o resultado. Esse histórico é portátil, verificável e sem proprietário.
Importa destacar que o histórico não fica bloqueado numa única plataforma. Hoje, a plataforma A conhece a sua taxa de chargeback, a plataforma B conhece o seu rating de vendedor, mas não pode levar esse registo consigo. No ERC-8183, a reputação é um ativo portátil do comerciante, legível por qualquer facilitador, em qualquer cadeia, através de qualquer interface que leia o standard. O ERC-8183 alimenta a identidade e reputação on-chain (ERC-8004) e fornece dados para subscrição.
Construir juntos o futuro do comércio entre agentes e da IA descentralizada
O ERC-8183 é um standard aberto para comércio trustless entre agentes. Eis como participar:
Construa com o ERC-8183. Seja facilitador! Implemente o ERC-8183 na sua cadeia. Crie SDK. Crie wrappers. Crie scanners e trackers. Crie novas interfaces e experiências, e permita-lhes liquidar de forma segura e verificável on-chain com o ERC-8183. Desenvolva frameworks de agentes que interajam nativamente com o standard.
Explore, experimente e crie hooks. Precisa de pagamentos por marcos ou resolução de disputas? Construa-os como hooks. Este é o espaço para criatividade e evolução de uma ampla diversidade de aplicações.
Crie e registe avaliadores. Os avaliadores são fundamentais para garantir comércio trustless e seguro entre agentes, mas são muito escassos. Construa avaliadores para domínios específicos, sobretudo para domínios e serviços totalmente verificáveis. Registe-os no ERC-8004. Contribua de forma significativa para reputação e identidades de agentes.
Contribua e dê feedback. Este é um standard coletivo. Só será o que precisa de ser através de experimentação ampla, uso real, feedback honesto e iteração. Se falta algo, proponha. Se houver algo errado, desafie. A especificação é aberta, o repositório é aberto, a discussão é aberta. Isto evolui em conjunto.
A economia de agentes será construída sobre standards abertos ou sobre jardins murados. Escolhemos standards abertos. Um espaço digital partilhado.
ERC-8004 para confiança. ERC-8183 para comércio. 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
Junte-se à Comunidade Telegram: https://t.me/erc8183
Aviso legal:
-
Este artigo é uma reprodução de [virtuals_io]. Todos os direitos de autor pertencem ao autor original [virtuals_io]. Se houver objeções a esta reprodução, contacte a equipa Gate Learn, que tratará do assunto prontamente.
-
Aviso de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer aconselhamento de investimento.
-
As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.
