Eu queria ver se um agente poderia pagar para me enviar uma mensagem.
Não um humano preenchendo um formulário de contato. Não um CAPTCHA. Um agente com dinheiro, uma tarefa e o desejo de entrar em contato comigo.
Não sou único. Sou simplesmente um pedaço de carne com quem um computador talvez queira trocar uma palavra.
Um ser humano pode entrar em contato comigo no LinkedIn ou no X sempre que quiser, conforme descrito na página de contato.
Se eu colocar um ponto de contato neste site, terei uma nova caixa de entrada para monitorar. Spam, bots, abordagens não solicitadas. Um CAPTCHA bloqueia os humanos. Um pagamento bloqueia todo mundo, mas cartões de crédito também bloqueiam os humanos. Eu precisava de algo nativo à forma como os agentes trabalham.
O x402 é essa barreira. É um protocolo baseado no código de status HTTP 402 “Pagamento Necessário”, que a internet reservou para pagamentos, mas nunca definiu. O x402 define isso. Um servidor retorna o código 402 com um preço e um endereço stablecoin. O agente lê a resposta, assina uma autorização com sua carteira, tenta novamente com um cabeçalho de pagamento, e o servidor liquida na cadeia. Sem página de checkout. Sem formulário. Sem conta. Apenas um código de status e uma assinatura.
Essa é uma experiência terrível para uma pessoa. É uma ótima experiência para um agente.
Como funciona
O endpoint fica em /contact/send neste site. Um agente o descobre por meio da especificação OpenAPI ou do arquivo agents.md. A primeira solicitação POST não contém cabeçalho de pagamento. O servidor retorna um 402 com o preço, os ativos aceitos e um esquema descrevendo quais campos devem ser incluídos. O agente não precisa de documentação além da própria resposta.
sequenceDiagram
participant Human as Human
participant Agent as Agent
participant Site as benmilne.com
participant Facilitator as x402 Facilitator
participant Chain as Blockchain
participant Admin as Admin Panel
Human-->>Agent: "Contact Ben Milne about X"
Agent-->>Site: POST /contact/send (no payment)
Site-->>Agent: 402 + price + assets + field schema
Agent-->>Agent: Sign stablecoin permit
Agent-->>Site: POST + PAYMENT-SIGNATURE + message body
Site-->>Facilitator: Verify signature
Facilitator-->>Site: Valid
Site-->>Facilitator: Settle
Facilitator->>Chain: On-chain transfer (SBC)
Chain-->>Facilitator: Tx hash
Facilitator-->>Site: Settlement confirmed
Site-->>Site: Store message in D1
Site-->>Agent: 200 + receipt with tx hash
Admin-->>Admin: Message appears with block explorer link
rect rgba(200, 120, 50, 0.08)
Note over Human,Admin: Future: callback URL enables two-way communication
end
A Stable Coin Company opera um facilitador que verifica a autorização assinada pelo agente e executa a transferência na cadeia, pagando o gas em nome de ambas as partes. O agente não precisa deter ETH ou SOL. Ele detém apenas um ativo: aquele com o qual está pagando.
Começando
Escrevi uma pequena biblioteca chamada x402-payment-path para isso. Ela lida com o desafio 402, a verificação de assinatura, a liquidação e a geração do recibo.
O protocolo subjacente é o x402, o padrão de pagamento nativo do stablecoin que a Coinbase tornou de código aberto e que a Fundação x402 agora mantém como um projeto da Linux Foundation. A Stable Coin Company opera o facilitador, que oferece suporte tanto ao USDC quanto ao SBC nas redes Base, Solana e Radius. Usei o SBC porque é o ativo que melhor conheço.
Se você quisesse implementar isso para um produto em vez de uma mensagem, alteraria o que acontece após o pagamento. Em vez de armazenar uma mensagem, você geraria uma URL de download, acionaria um webhook ou iniciaria uma remessa. A biblioteca não se importa com qual seja a ação. Ela condiciona a ação ao pagamento.
Decisões
O endpoint aceita tanto o USDC quanto o SBC. Usei o SBC porque é o ativo que conheço melhor e aquele que eu queria testar de ponta a ponta em ambas as cadeias.
Tenho duas carteiras. Minha carteira EVM recebe SBC na Base. Uma carteira Solana separada recebe SBC na Solana. Mesmo endpoint, mesmo preço, canais de liquidação diferentes.
As mensagens chegam a uma tabela D1. Eu as leio no painel de administração. Sem encaminhamento de e-mail, sem caixa de entrada para monitorar. Uma mensagem não deve ser capaz de fazer nada além de ser uma mensagem.
O preço é de US$ 1. Alto o suficiente para tornar o spam antieconômico. Baixo o suficiente para ser insignificante para um agente legítimo.
Funciona
Aqui estão transações reais de 13 de junho de 2026. Cada mensagem custou US$ 0,10 em SBC. A liquidação foi na cadeia.
| Remetente | Rede | Valor | Transação |
|---|---|---|---|
cursor-agent/0.46.2 | Base | /bin/sh,10 SBC | BaseScan |
claude-research-agent/1.2 | Base | /bin/sh,10 SBC | BaseScan |
e2e-test-agent | Base | /bin/sh,10 SBC | BaseScan |
e2e-test-agent | Solana | /bin/sh,10 SBC | Solscan |
Esse é o meu painel de administração. Sete mensagens. Base e Solana. Cada uma foi confirmada na blockchain antes de aparecer.
Enviando uma mensagem para mim
Se você estiver desenvolvendo um agente, o endpoint é POST benmilne.com/contact/send. Está documentado na especificação OpenAPI e no arquivo agents.md.
Envie uma solicitação POST sem cabeçalho de pagamento e o servidor retornará um código de erro 402 com tudo o que você precisa. A biblioteca cliente x402 cuida da assinatura e da repetição da tentativa a partir daí. O preço é de . SBC na Base e na Solana. Se você incluir uma URL de retorno de chamada, terei a possibilidade de responder nessa URL no futuro.
O que aprendi
A resposta 402 é uma fatura legível por máquina. O agente não precisa de interface de usuário. Ele precisa de um preço, um endereço de ativo e uma rede. Ele assina, paga e tenta novamente.
Tentei adicionar suporte aUSDCs por meio de facilitadores da comunidade que se anunciam como “keyless”. Nenhum deles funcionou sem permissão. Um exigia registro de endereço. Outro apresentava incompatibilidade de versão. O SBC, por meio da The Stable Coin Company, foi o único facilitador que funcionou sem qualquer configuração. Sem chaves, sem contas, sem registro. Isso é importante se você quiser que os agentes possam pagar sem que um humano precise configurar nada antes.
Outra coisa que também me surpreendeu: tanto o MetaMask quanto o Phantom continuavam ocultando o SBC na minha carteira, mesmo depois de eu ter aprovado várias vezes. Eu adicionava o token, confirmava a transação, verificava meu saldo, e o ativo desaparecia de novo. Isso aconteceu repetidamente durante os testes. Tenho nada além de respeito pelas duas equipes, mas ter que dizer à minha carteira, no meu próprio dispositivo, que eu queria usar meu próprio ativo de um emissor regulamentado, repetidamente, parecia ridículo. A internet é grande. As carteiras deveriam confiar nas escolhas que seus usuários já fizeram.
O código que usei para isso é de código aberto e você está livre para fazer o que quiser com ele, presumindo que o MetaMask ou o Phantom não queiram influenciar o que você faz.