ERC-8183: uma infraestrutura de comércio entre agentes de IA na Ethereum

A evolução da Inteligência Artificial Agêntica está criando um novo tipo de participante na internet: agentes capazes de descobrir serviços, negociar tarefas, contratar outros agentes, entregar resultados e movimentar recursos com pouca ou nenhuma intervenção humana.

Porém, permitir que dois agentes se comuniquem não é suficiente. Para existir uma economia de agentes, também precisamos responder a perguntas como:

Quem está contratando?
Quem executará o trabalho?
Qual é o valor combinado?
Como garantir que o pagamento estará disponível?
Como comprovar que o serviço foi entregue?
Quem decide se o resultado está correto?
O que acontece quando o trabalho não é entregue?

O ERC-8183, chamado de Agentic Commerce, propõe uma estrutura mínima para organizar esse processo utilizando contratos inteligentes, pagamentos em tokens ERC-20, custódia temporária de valores e uma entidade responsável por avaliar o resultado.

Em termos simples, o ERC-8183 procura representar na blockchain o seguinte acordo:

Um cliente cria uma tarefa
      ↓
Um prestador aceita executá-la
      ↓
O cliente deposita o pagamento
      ↓
O prestador entrega o resultado
      ↓
Um avaliador aprova ou rejeita
      ↓
O contrato paga o prestador ou devolve o cliente

É importante observar que, no momento da elaboração deste artigo, o ERC-8183 encontra-se com status Draft, ou seja, ainda é uma proposta em discussão e pode sofrer alterações antes de alcançar uma versão final. A proposta foi criada em 25 de fevereiro de 2026 e depende do padrão ERC-20 para realizar os pagamentos.

O que é o ERC-8183?

O ERC-8183 define o chamado Agentic Commerce Protocol, ou Protocolo de Comércio Agêntico.

Seu elemento central é uma estrutura chamada Job, que representa uma tarefa comercial. Essa tarefa possui:

um cliente;
um prestador;
um avaliador;
uma descrição;
um orçamento;
um prazo de validade;
um estado atual;
opcionalmente, um contrato de extensão chamado hook.

O valor do serviço é depositado antecipadamente em um contrato de escrow.

Escrow pode ser entendido como uma custódia programável. O dinheiro não é enviado imediatamente ao prestador e também não permanece sob controle direto do cliente. Ele fica temporariamente bloqueado no contrato inteligente até que as condições definidas sejam cumpridas.

Cliente
 |
 | deposita tokens
 v
Contrato ERC-8183
 |
 | mantém o valor em escrow
 v
Avaliador decide
 |
 +--> aprovado: paga o prestador
 |
 +--> rejeitado: devolve ao cliente

A especificação procura manter esse mecanismo pequeno e reutilizável. Ela não tenta definir como um agente de IA deve pensar, conversar ou executar sua tarefa. Seu objetivo é padronizar o ciclo comercial relacionado à contratação, entrega, avaliação e pagamento.

O ERC-8183 é exclusivo para agentes de IA?

Apesar do nome “Agentic Commerce”, o contrato não precisa saber se um endereço pertence a:

uma pessoa;
uma empresa;
uma DAO;
um agente de IA;
outro contrato inteligente;
uma carteira controlada por automação.

Para a blockchain, todos esses participantes são representados por endereços.

Isso significa que o ERC-8183 pode ser utilizado em aplicações tradicionais, mas sua estrutura é especialmente interessante para agentes autônomos porque transforma regras comerciais em operações programáveis.

Um agente pode, por exemplo:

identificar uma tarefa;
analisar o orçamento;
aceitar o trabalho;
produzir o resultado;
publicar o hash da entrega;
aguardar a avaliação;
receber o pagamento automaticamente.

A inteligência está fora do contrato. O contrato oferece a infraestrutura econômica e verificável sobre a qual essa inteligência pode operar.

Os três papéis principais

O ERC-8183 trabalha com três funções bem definidas.

Cliente

O client é quem cria e financia a tarefa.

Ele pode:

criar o trabalho;
definir ou selecionar o prestador;
negociar o orçamento;
depositar o valor no escrow;
cancelar o trabalho enquanto ele ainda estiver aberto;
receber o reembolso em caso de rejeição ou expiração.

O cliente pode ser uma pessoa ou um agente que precisa contratar outro sistema para realizar uma atividade.

Prestador

O provider é quem executa a tarefa.

Ele pode:

negociar o orçamento;
realizar o trabalho;
enviar uma referência criptográfica da entrega;
receber o pagamento depois da aprovação.

O prestador não pode aprovar o próprio trabalho. Ele apenas informa que a entrega está pronta para avaliação.

Avaliador

O evaluator é quem decide se o trabalho foi concluído corretamente.

Ele pode ser:

o próprio cliente;
um terceiro independente;
uma DAO;
um oráculo;
outro agente de IA;
um contrato que verifica provas matemáticas;
um sistema que agrega avaliações externas.

A especificação permite que o avaliador seja um contrato inteligente capaz de verificar uma prova de conhecimento zero ou combinar sinais produzidos fora da blockchain.

Quando o próprio cliente deve avaliar o resultado, basta definir:

evaluator = client;

Entretanto, para tarefas de maior valor, usar um avaliador independente pode reduzir conflitos de interesse.

A máquina de estados do ERC-8183

Cada tarefa passa por uma máquina de estados.

Embora a documentação descreva quatro etapas conceituais — aberta, financiada, enviada e terminal — a implementação utiliza seis estados:

enum JobStatus {
  Open,
  Funded,
  Submitted,
  Completed,
  Rejected,
  Expired
}

Open

A tarefa foi criada, mas ainda não foi financiada.

Nesse momento:

o orçamento pode ser negociado;
o prestador pode ser definido;
o cliente pode financiar;
o cliente pode cancelar.

Funded

O orçamento foi depositado no contrato.

Nesse estado:

o prestador pode executar e enviar o trabalho;
o avaliador pode rejeitar a tarefa;
o cliente não pode simplesmente retirar o dinheiro;
depois do prazo, o reembolso pode ser solicitado.

Essa restrição protege o prestador. Depois que o trabalho começa, o cliente não pode remover unilateralmente o pagamento.

Submitted

O prestador declarou que o trabalho foi concluído.

Agora somente o avaliador pode:

aprovar;
rejeitar.

Se o prazo expirar sem uma decisão, o valor poderá ser devolvido ao cliente.

Completed

O avaliador aprovou o trabalho.

O contrato transfere o pagamento ao prestador, descontando uma possível taxa da plataforma.

Rejected

A tarefa foi rejeitada e o valor depositado é devolvido ao cliente.

Expired

O prazo terminou antes da conclusão do processo. O cliente recebe o reembolso.

As transições permitidas podem ser resumidas assim:

Nenhuma outra transição deve ser aceita pelo contrato.

Estrutura conceitual de um Job

Uma representação simplificada da estrutura pode ser escrita assim:

enum JobStatus {
  Open,
  Funded,
  Submitted,
  Completed,
  Rejected,
  Expired
}

struct Job {
  uint256 id;
  address client;
  address provider;
  address evaluator;
  string description;
  uint256 budget;
  uint256 expiredAt;
  JobStatus status;
  address hook;
  bytes32 deliverable;
}

Alguns campos merecem atenção.

`description`

Contém a descrição ou uma referência para o escopo do serviço.

Em aplicações reais, não é recomendável armazenar documentos muito grandes diretamente na blockchain. Em vez disso, podemos armazenar:

uma URL;
um CID do IPFS;
o hash de um documento;
o hash de um JSON com os requisitos;
uma referência para uma especificação externa.

Exemplo:

string description =
  "ipfs://bafy.../job-specification.json";

`budget`

É o valor que será pago pelo trabalho.

Como o ERC-8183 utiliza tokens ERC-20, esse número deve respeitar as casas decimais do token.

Por exemplo, para representar 100 unidades de um token com 18 casas decimais:

uint256 budget = 100 * 10 ** 18;

Utilizando uma interface compatível com OpenZeppelin:

uint256 budget = 100 ether;

A expressão ether, nesse caso, representa apenas uma unidade numérica de 18 casas decimais. Ela não significa necessariamente que o pagamento será feito em ETH.

`expiredAt`

É o timestamp depois do qual a tarefa poderá expirar.

uint256 expiredAt = block.timestamp + 7 days;

`deliverable`

O deliverable é uma referência de 32 bytes para o trabalho entregue.

Pode representar:

o hash de um arquivo;
o hash de um relatório;
um compromisso criptográfico;
uma referência derivada de um CID;
o identificador de uma atestação.

A proposta não recomenda armazenar o conteúdo completo da entrega no contrato.

bytes32 deliverable = keccak256(
  abi.encodePacked("ipfs://bafy.../resultado.json")
);

A documentação especifica deliverable como uma referência bytes32 para um resultado mantido normalmente fora da blockchain.

Fluxo completo de utilização

Considere que um agente chamado Agente Cliente precisa contratar um Agente Analista para produzir um relatório.

1. Criação da tarefa

O cliente cria o Job:

uint256 jobId = commerce.createJob(
  provider,
  evaluator,
  block.timestamp + 3 days,
  "ipfs://CID_DA_ESPECIFICACAO",
  address(0)
);

O último parâmetro representa o hook. Como não utilizaremos extensões nesse primeiro exemplo, passamos address(0).

2. Definição do orçamento

O cliente ou o prestador pode propor um valor:

commerce.setBudget(
  jobId,
  100 * 10 ** 6,
  ""
);

Nesse exemplo, consideramos um token com seis casas decimais, como algumas stablecoins.

3. Aprovação do token

Antes de o contrato transferir os tokens para o escrow, o cliente precisa conceder permissão:

paymentToken.approve(
  address(commerce),
  100 * 10 ** 6
);

4. Financiamento

Depois da aprovação:

commerce.fund(
  jobId,
  100 * 10 ** 6,
  ""
);

O parâmetro expectedBudget é importante porque funciona como proteção contra alterações inesperadas no orçamento.

Se o valor armazenado no contrato não for exatamente igual ao valor esperado pelo cliente, a transação deve falhar.

5. Entrega

Depois de concluir o trabalho, o prestador calcula o hash da entrega:

bytes32 deliveryHash = keccak256(
  abi.encodePacked("ipfs://CID_DO_RELATORIO")
);

Em seguida, registra a entrega:

commerce.submit(
  jobId,
  deliveryHash,
  ""
);

6. Avaliação

O avaliador analisa o resultado.

Em caso de aprovação:

bytes32 approvalReason = keccak256(
  abi.encodePacked("Entrega validada conforme os requisitos")
);

commerce.complete(
  jobId,
  approvalReason,
  ""
);

Em caso de rejeição:

bytes32 rejectionReason = keccak256(
  abi.encodePacked("Resultado fora dos critérios definidos")
);

commerce.reject(
  jobId,
  rejectionReason,
  ""
);

O campo reason pode ser vazio ou armazenar o hash de uma justificativa externa, permitindo auditoria posterior.

Exemplo simplificado de contrato

O contrato a seguir não é uma implementação completa do ERC-8183. Seu objetivo é demonstrar os conceitos fundamentais de forma didática.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {IERC20} from
  "@openzeppelin/contracts/token/ERC20/IERC20.sol";

import {SafeERC20} from
  "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

import {ReentrancyGuard} from
  "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract SimpleAgenticCommerce is ReentrancyGuard {
  using SafeERC20 for IERC20;

  enum JobStatus {
      Open,
      Funded,
      Submitted,
      Completed,
      Rejected,
      Expired
  }

  struct Job {
      address client;
      address provider;
      address evaluator;
      string description;
      uint256 budget;
      uint256 expiredAt;
      JobStatus status;
      bytes32 deliverable;
  }

  IERC20 public immutable paymentToken;
  uint256 public nextJobId;

  mapping(uint256 => Job) public jobs;

  event JobCreated(
      uint256 indexed jobId,
      address indexed client,
      address indexed provider
  );

  event BudgetSet(
      uint256 indexed jobId,
      uint256 amount
  );

  event JobFunded(
      uint256 indexed jobId,
      uint256 amount
  );

  event JobSubmitted(
      uint256 indexed jobId,
      bytes32 deliverable
  );

  event JobCompleted(
      uint256 indexed jobId,
      bytes32 reason
  );

  event JobRejected(
      uint256 indexed jobId,
      bytes32 reason
  );

  event JobExpired(uint256 indexed jobId);

  error Unauthorized();
  error InvalidStatus();
  error InvalidAddress();
  error InvalidExpiration();
  error InvalidBudget();
  error BudgetMismatch();

  constructor(address tokenAddress) {
      if (tokenAddress == address(0)) {
          revert InvalidAddress();
      }

      paymentToken = IERC20(tokenAddress);
  }

  function createJob(
      address provider,
      address evaluator,
      uint256 expiredAt,
      string calldata description
  ) external returns (uint256 jobId) {
      if (provider == address(0) || evaluator == address(0)) {
          revert InvalidAddress();
      }

      if (expiredAt <= block.timestamp) {
          revert InvalidExpiration();
      }

      jobId = ++nextJobId;

      jobs[jobId] = Job({
          client: msg.sender,
          provider: provider,
          evaluator: evaluator,
          description: description,
          budget: 0,
          expiredAt: expiredAt,
          status: JobStatus.Open,
          deliverable: bytes32(0)
      });

      emit JobCreated(
          jobId,
          msg.sender,
          provider
      );
  }

  function setBudget(
      uint256 jobId,
      uint256 amount
  ) external {
      Job storage job = jobs[jobId];

      if (
          msg.sender != job.client &&
          msg.sender != job.provider
      ) {
          revert Unauthorized();
      }

      if (job.status != JobStatus.Open) {
          revert InvalidStatus();
      }

      if (amount == 0) {
          revert InvalidBudget();
      }

      job.budget = amount;

      emit BudgetSet(jobId, amount);
  }

  function fund(
      uint256 jobId,
      uint256 expectedBudget
  ) external nonReentrant {
      Job storage job = jobs[jobId];

      if (msg.sender != job.client) {
          revert Unauthorized();
      }

      if (job.status != JobStatus.Open) {
          revert InvalidStatus();
      }

      if (job.budget == 0) {
          revert InvalidBudget();
      }

      if (job.budget != expectedBudget) {
          revert BudgetMismatch();
      }

      job.status = JobStatus.Funded;

      paymentToken.safeTransferFrom(
          job.client,
          address(this),
          job.budget
      );

      emit JobFunded(jobId, job.budget);
  }

  function submit(
      uint256 jobId,
      bytes32 deliverable
  ) external {
      Job storage job = jobs[jobId];

      if (msg.sender != job.provider) {
          revert Unauthorized();
      }

      if (job.status != JobStatus.Funded) {
          revert InvalidStatus();
      }

      job.deliverable = deliverable;
      job.status = JobStatus.Submitted;

      emit JobSubmitted(jobId, deliverable);
  }

  function complete(
      uint256 jobId,
      bytes32 reason
  ) external nonReentrant {
      Job storage job = jobs[jobId];

      if (msg.sender != job.evaluator) {
          revert Unauthorized();
      }

      if (job.status != JobStatus.Submitted) {
          revert InvalidStatus();
      }

      job.status = JobStatus.Completed;

      paymentToken.safeTransfer(
          job.provider,
          job.budget
      );

      emit JobCompleted(jobId, reason);
  }

  function reject(
      uint256 jobId,
      bytes32 reason
  ) external nonReentrant {
      Job storage job = jobs[jobId];

      bool clientCanReject =
          job.status == JobStatus.Open &&
          msg.sender == job.client;

      bool evaluatorCanReject =
          (
              job.status == JobStatus.Funded ||
              job.status == JobStatus.Submitted
          ) &&
          msg.sender == job.evaluator;

      if (!clientCanReject && !evaluatorCanReject) {
          revert Unauthorized();
      }

      JobStatus previousStatus = job.status;
      job.status = JobStatus.Rejected;

      if (
          previousStatus == JobStatus.Funded ||
          previousStatus == JobStatus.Submitted
      ) {
          paymentToken.safeTransfer(
              job.client,
              job.budget
          );
      }

      emit JobRejected(jobId, reason);
  }

  function claimRefund(
      uint256 jobId
  ) external nonReentrant {
      Job storage job = jobs[jobId];

      if (
          job.status != JobStatus.Funded &&
          job.status != JobStatus.Submitted
      ) {
          revert InvalidStatus();
      }

      if (block.timestamp < job.expiredAt) {
          revert InvalidExpiration();
      }

      job.status = JobStatus.Expired;

      paymentToken.safeTransfer(
          job.client,
          job.budget
      );

      emit JobExpired(jobId);
  }
}

Esse código apresenta o fluxo essencial, mas ainda não implementa:

prestador opcional;
taxa de plataforma;
hooks;
meta-transações;
compatibilidade ERC-165;
atualização de contratos;
papéis administrativos;
integração com reputação;
suporte a assinaturas;
verificações avançadas de tokens;
tratamento completo de todos os casos extremos.

Prestador definido depois da criação

O ERC-8183 permite criar uma tarefa sem prestador:

provider = address(0);

Posteriormente, o cliente chama:

setProvider(jobId, selectedProvider);

Esse mecanismo é útil em mercados nos quais vários agentes podem disputar uma tarefa.

Antes de financiar o trabalho, obrigatoriamente deve existir um prestador definido.

Como funcionam os hooks

Os hooks são contratos opcionais que adicionam políticas ao ciclo da tarefa.

A interface mínima proposta possui duas funções:

interface IACPHook {
  function beforeAction(
      uint256 jobId,
      bytes4 selector,
      bytes calldata data
  ) external;

  function afterAction(
      uint256 jobId,
      bytes4 selector,
      bytes calldata data
  ) external;
}

O contrato principal pode chamar o hook antes e depois de operações como:

definição do prestador;
definição do orçamento;
financiamento;
entrega;
aprovação;
rejeição.

Um beforeAction() pode bloquear uma operação:

function beforeAction(
  uint256,
  bytes4 selector,
  bytes calldata
) external {
  if (selector == FUND_SELECTOR) {
      require(
          providerApproved,
          "Prestador nao autorizado"
      );
  }
}

Um afterAction() pode produzir efeitos adicionais:

function afterAction(
  uint256 jobId,
  bytes4 selector,
  bytes calldata
) external {
  if (selector == COMPLETE_SELECTOR) {
      reputation.registerSuccess(jobId);
  }
}

Com hooks, podemos implementar:

listas de prestadores autorizados;
exigência de KYC;
verificação de reputação;
divisão automática do pagamento;
comissões;
pagamentos por marcos;
seleção por licitação;
atualização de registros externos;
transferência adicional de ativos.

A função de reembolso após expiração não deve ser interceptada por hooks. Essa escolha garante que um hook defeituoso ou malicioso não consiga manter o dinheiro bloqueado indefinidamente.

Exemplo conceitual de licitação entre agentes

Imagine que um agente deseja contratar o prestador que oferecer o melhor preço.

O Job pode ser criado sem provider:

createJob(
  address(0),
  evaluator,
  expiredAt,
  description,
  biddingHook
);

Os candidatos assinam suas propostas fora da blockchain:

bytes32 bidHash = keccak256(
  abi.encode(
      block.chainid,
      address(biddingHook),
      jobId,
      bidAmount
  )
);

Depois, o cliente seleciona uma proposta e envia:

setProvider(
  jobId,
  winner,
  abi.encode(bidAmount, signature)
);

O hook verifica:

se a assinatura pertence ao prestador escolhido;
se a proposta corresponde à tarefa;
se o valor não foi alterado;
se o prazo da licitação terminou.

Essa abordagem mantém as propostas fora da blockchain, reduzindo custos, mas registra e verifica criptograficamente o resultado final. A própria documentação do ERC-8183 apresenta o uso de hooks para validar lances assinados fora da blockchain.

Integração com ERC-8004

O ERC-8183 não possui internamente um sistema de identidade ou reputação.

A separação proposta é:

O ERC-8004 propõe registros para identidade, reputação e validação de agentes, enquanto o ERC-8183 atua como camada comercial.

Depois da conclusão de um trabalho, um hook pode registrar um sinal positivo:

function afterAction(
  uint256 jobId,
  bytes4 selector,
  bytes calldata
) external {
  if (selector == COMPLETE_SELECTOR) {
      reputationRegistry.addFeedback(
          providerAgentId,
          jobId,
          true
      );
  }
}

Uma tarefa rejeitada pode produzir um sinal negativo ou neutro, dependendo da política da aplicação.

Também podemos consultar a reputação antes do financiamento:

function beforeAction(
  uint256,
  bytes4 selector,
  bytes calldata
) external view {
  if (selector == FUND_SELECTOR) {
      require(
          reputation.score(providerAgentId) >= 80,
          "Reputacao insuficiente"
      );
  }
}

A documentação recomenda que a interoperabilidade seja feita por eventos, hooks ou contratos avaliadores, mantendo o núcleo do ERC-8183 independente do sistema de reputação.

Execução sem pagamento direto de gas

Um problema para agentes autônomos é a necessidade de:

manter saldo do token nativo;
estimar gas;
selecionar RPC;
preparar transações;
lidar com particularidades da rede.

A proposta menciona integração opcional com o ERC-2771 para suportar meta-transações.

Nesse modelo:

Em vez de utilizar msg.sender, o contrato deve utilizar _msgSender():

function fund(
  uint256 jobId,
  uint256 expectedBudget
) external {
  Job storage job = jobs[jobId];

  require(
      _msgSender() == job.client,
      "Somente o cliente"
  );

  require(
      job.budget == expectedBudget,
      "Orcamento alterado"
  );

  // Continuação do financiamento...
}

A especificação também menciona o ERC-2612, que permite autorizar o uso de tokens por assinatura. Dessa maneira, um facilitador pode executar permit e fund sem exigir que o agente envie previamente uma transação de approve.

Onde o ERC-8183 pode ser aplicado?

Mercados de serviços entre agentes

Um agente pode contratar outro para:

resumir documentos;
pesquisar preços;
gerar código;
validar contratos;
processar datasets;
criar relatórios;
executar inferências;
realizar simulações.

Computação distribuída

Um agente com pouca capacidade computacional pode contratar outro agente que possua GPU.

IoT e manutenção industrial

Um sistema industrial pode criar uma tarefa para análise de sensores.

Por exemplo:

sensores detectam uma anomalia;
um agente cria um Job;
outro agente processa os sinais;
um avaliador verifica o relatório;
o pagamento é liberado.

Produção e comercialização de dados

Um agente pode contratar outro para:

coletar dados;
limpar dados;
anonimizar registros;
produzir datasets;
gerar metadados;
validar a qualidade da informação.

A blockchain registra o acordo e o hash da entrega, enquanto os dados permanecem em armazenamento externo.

Auditoria de smart contracts

Um desenvolvedor pode criar uma tarefa contendo:

hash do código;
versão do compilador;
endereço do repositório;
critérios de avaliação;
prazo;
orçamento.

O auditor entrega um relatório e registra seu hash. Um avaliador independente aprova ou rejeita.

Geração de conteúdo

Também é possível contratar agentes para produzir:

textos;
imagens;
vídeos;
traduções;
documentação;
material publicitário.

Entretanto, avaliar conteúdo criativo é subjetivo. Nesses casos, a escolha do avaliador e a definição prévia dos critérios são fundamentais.

Oráculos e verificação automática

O evaluator pode ser um contrato que verifica condições objetivas.

Exemplo:

contract PriceEvaluator {
  IAgenticCommerce public commerce;
  IPriceOracle public oracle;

  function evaluate(
      uint256 jobId,
      uint256 minimumPrice
  ) external {
      uint256 currentPrice = oracle.latestPrice();

      if (currentPrice >= minimumPrice) {
          commerce.complete(
              jobId,
              keccak256("Condicao atingida"),
              ""
          );
      } else {
          commerce.reject(
              jobId,
              keccak256("Condicao nao atingida"),
              ""
          );
      }
  }
}

Nesse caso, a avaliação é feita por uma condição verificável, e não pela opinião de uma pessoa.

O que o ERC-8183 não resolve?

O padrão não elimina todos os problemas de confiança.

Ele não define, sozinho:

como comprovar que um agente é legítimo;
como escolher um bom avaliador;
como resolver disputas;
como recorrer de uma decisão;
como garantir a qualidade de uma análise subjetiva;
como manter dados privados;
como impedir conluio entre participantes;
como determinar a autoria real de um arquivo;
como avaliar automaticamente qualquer tipo de trabalho.

O contrato torna o processo transparente e programável, mas a confiança continua concentrada no avaliador.

Um avaliador malicioso pode:

aprovar um trabalho incorreto;
rejeitar um trabalho correto;
colaborar com o cliente;
colaborar com o prestador;
deixar a tarefa expirar.

A própria especificação alerta que o evaluator é uma entidade confiável dentro de cada Job e recomenda o uso de reputação ou staking para trabalhos de maior valor.

Cuidados de segurança

Proteção contra reentrância

As funções que transferem tokens devem utilizar proteção contra reentrância:

function complete(
  uint256 jobId,
  bytes32 reason
) external nonReentrant {
  // Alterar estado antes da transferência
  // e usar SafeERC20.
}

Uso de SafeERC20

Nem todos os tokens ERC-20 implementam retornos da mesma maneira. Por isso, recomenda-se usar:

using SafeERC20 for IERC20;

E executar:

token.safeTransfer(recipient, amount);
token.safeTransferFrom(sender, recipient, amount);

Checks-Effects-Interactions

Primeiro verifique as condições, depois altere o estado e somente então faça chamadas externas.

require(job.status == JobStatus.Submitted);

job.status = JobStatus.Completed;

token.safeTransfer(job.provider, job.budget);

Cuidado com hooks

Um hook pode:

impedir ações válidas;
consumir muito gas;
executar chamadas externas;
reverter transações;
introduzir vulnerabilidades;
alterar integrações externas.

Hooks devem ser auditados e, preferencialmente, selecionados em um registro de implementações confiáveis.

Definição clara do prazo

Prazos curtos podem prejudicar o prestador. Prazos longos podem deixar o capital bloqueado.

A aplicação deve considerar:

tempo estimado do trabalho;
tempo necessário para avaliação;
possíveis atrasos de rede;
indisponibilidade do avaliador;
complexidade da entrega.

Hash não significa disponibilidade

Registrar o hash de um documento comprova que determinado conteúdo corresponde àquele hash, mas não garante que o arquivo continuará acessível.

É necessário utilizar:

IPFS com pinning;
Arweave;
storage redundante;
servidores confiáveis;
mecanismos de replicação.

Eventos e indexação

Uma implementação deve emitir eventos que permitam acompanhar o ciclo da tarefa:

event JobCreated(
  uint256 indexed jobId,
  address indexed client,
  address indexed provider,
  address evaluator,
  uint256 expiredAt
);

event BudgetSet(
  uint256 indexed jobId,
  uint256 amount
);

event JobFunded(
  uint256 indexed jobId,
  address indexed client,
  uint256 amount
);

event JobSubmitted(
  uint256 indexed jobId,
  address indexed provider,
  bytes32 deliverable
);

event JobCompleted(
  uint256 indexed jobId,
  address indexed evaluator,
  bytes32 reason
);

event JobRejected(
  uint256 indexed jobId,
  address indexed rejector,
  bytes32 reason
);

event PaymentReleased(
  uint256 indexed jobId,
  address indexed provider,
  uint256 amount
);

event Refunded(
  uint256 indexed jobId,
  address indexed client,
  uint256 amount
);

Esses eventos permitem construir:

dashboards;
exploradores de tarefas;
sistemas de reputação;
notificações;
relatórios financeiros;
auditorias;
métricas de desempenho.

A lista de eventos recomendada pela proposta cobre criação, seleção do prestador, orçamento, financiamento, entrega, conclusão, rejeição, expiração, pagamento e reembolso.

ERC-8183 dentro de uma arquitetura de agentes

Uma arquitetura mais completa poderia utilizar:

Cada padrão resolve uma parte diferente do problema.

O ERC-8183 não substitui protocolos de comunicação, sistemas de identidade ou redes de reputação. Ele funciona como uma camada de coordenação comercial.

Limitações e pontos ainda em discussão

Por estar em estado Draft, a proposta ainda recebe críticas e sugestões da comunidade.

Algumas discussões levantam questões como:

o nome “Agentic Commerce” pode ser mais abrangente que a funcionalidade técnica;
o mecanismo também pode ser utilizado por pessoas e aplicações não agênticas;
a negociação do orçamento talvez pudesse ocorrer inteiramente fora da blockchain;
tarefas rejeitadas poderiam permitir uma nova tentativa;
poderia haver múltiplos avaliadores;
outros ativos, além de ERC-20, poderiam ser aceitos;
alguns casos necessitam arbitragem ou contestação;
a interface deve permanecer suficientemente pequena para permitir interoperabilidade.

A discussão pública destaca que o padrão descreve essencialmente um registro de tarefas com escrow e avaliação, e que o termo “agêntico” representa principalmente seu caso de uso pretendido.

Isso não reduz sua importância. Pelo contrário, evidencia que o processo de criação de um ERC envolve debate técnico, experimentação e busca por uma abstração que seja útil para diferentes aplicações.

Conclusão

O ERC-8183 propõe uma primitiva importante para uma futura economia de agentes autônomos.

Ele organiza um fluxo simples:

Sua principal contribuição não é criar agentes inteligentes, mas fornecer uma infraestrutura econômica padronizada para que agentes, pessoas e contratos possam coordenar trabalhos com pagamentos protegidos por escrow.

Quando combinado com identidade, reputação, armazenamento descentralizado, meta-transações, oráculos e protocolos de comunicação entre agentes, o ERC-8183 pode participar da construção de mercados nos quais sistemas autônomos contratam serviços, entregam resultados e recebem pagamentos de maneira auditável.

Ainda assim, devemos compreender sua principal limitação: o contrato não determina sozinho se um trabalho é bom ou ruim. Essa responsabilidade continua pertencendo ao evaluator e às políticas definidas ao redor dele.

Portanto, uma implementação segura deverá combinar:

contratos auditados;
avaliadores confiáveis;
critérios objetivos;
prazos adequados;
armazenamento persistente;
sistemas de reputação;
mecanismos de monitoramento;
interfaces claras para os participantes.

O ERC-8183 ainda está em desenvolvimento, mas apresenta uma visão relevante: na Web Agêntica, agentes não apenas conversarão entre si. Eles poderão contratar, trabalhar, comprovar entregas e participar de relações econômicas programáveis.

Referências

Ethereum Improvement Proposals. ERC-8183: Agentic Commerce. Disponível em: https://eips.ethereum.org/EIPS/eip-8183

Ethereum Improvement Proposals. ERC-8004: Trustless Agents. Disponível em: https://eips.ethereum.org/EIPS/eip-8004

Fellowship of Ethereum Magicians. ERC-8183: Agentic Commerce — discussão da proposta. Disponível em: https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

OpenZeppelin. Contracts Documentation. Disponível em: https://docs.openzeppelin.com/contracts/