Quería comprobar si un agente podía pagar para enviarme un mensaje.
No un humano rellenando un formulario de contacto. Ni un CAPTCHA. Un agente con dinero, una tarea y ganas de ponerse en contacto conmigo.
No soy único. Simplemente soy un trozo de carne al que un ordenador podría querer decirle algo.
Un humano puede ponerse en contacto conmigo en LinkedIn o en X cuando quiera, tal y como se indica en la página de contacto.
Si incluyo un punto de contacto en esta web, tendré que vigilar otra bandeja de entrada más. Spam, bots, contactos no solicitados. Un CAPTCHA filtra a los humanos. Un pago filtra a todo el mundo, pero las tarjetas de crédito también filtran a los humanos. Necesitaba algo propio de cómo funcionan los agentes.
x402 es esa barrera. Es un protocolo basado en el código de estado HTTP 402 «Pago requerido», que Internet reservó para los pagos pero nunca definió. x402 lo define. Un servidor devuelve un 402 con un precio y una dirección stablecoin. El agente lee la respuesta, firma un permiso con su monedero, vuelve a intentarlo con un encabezado de pago y el servidor liquida la transacción en la cadena. Sin página de pago. Sin formulario. Sin cuenta. Solo un código de estado y una firma.
Es una experiencia terrible para una persona. Es una experiencia fantástica para un agente.
Cómo funciona
El punto final se encuentra en /contact/send en este sitio web. Un agente lo descubre a través de la especificación OpenAPI o del archivo agents.md. La primera solicitud POST no incluye un encabezado de pago. El servidor devuelve un código 402 con el precio, los activos aceptados y un esquema que describe qué campos hay que incluir. El agente no necesita más documentación que la propia respuesta.
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
The Stable Coin Company gestiona un facilitador que verifica el permiso firmado por el agente y ejecuta la transferencia en cadena, pagando el gas en nombre de ambas partes. El agente no necesita tener ETH ni SOL. Solo tiene un activo: aquel con el que está pagando.
Cómo empezar
Para ello, he escrito una pequeña biblioteca llamada x402-payment-path. Se encarga del desafío 402, la verificación de la firma, la liquidación y la generación del recibo.
El protocolo subyacente es x402, el estándar de pago nativo de la «stablecoin» que Coinbase convirtió en código abierto y que ahora mantiene la Fundación x402 como proyecto de la Linux Foundation. The Stable Coin Company gestiona el facilitador, que es compatible tanto con «USDC» como con SBC en Base, Solana y Radius. Utilicé SBC porque es el activo que mejor conozco.
Si quisieras implementar esto para un producto en lugar de para un mensaje, cambiarías lo que ocurre tras el pago. En lugar de almacenar un mensaje, generarías una URL de descarga, activarías un webhook o iniciarías un envío. A la biblioteca no le importa cuál sea la acción. Simplemente condiciona la acción al pago.
Decisiones
El punto final acepta tanto «USDC» como SBC. He utilizado SBC porque es el activo que mejor conozco y el que quería verificar de principio a fin en ambas cadenas.
Tengo dos carteras. Mi cartera EVM recibe SBC en Base. Otra cartera de Solana recibe SBC en Solana. Mismo punto final, mismo precio, diferentes vías de liquidación.
Los mensajes llegan a una tabla D1. Los leo en el panel de administración. Sin reenvío de correos electrónicos, sin bandeja de entrada que supervisar. Un mensaje no debería poder hacer nada más que ser un mensaje.
El precio es de 1 $. Lo suficientemente alto como para que el spam resulte antieconómico. Lo suficientemente bajo como para que resulte insignificante para un agente legítimo.
Funciona
Aquí hay transacciones reales del 13 de junio de 2026. Cada mensaje costó 0,10 $ en SBC. La liquidación se realizó en la cadena.
| Remitente | Red | Importe | Transacción |
|---|---|---|---|
cursor-agent/0.46.2 | Base | 0,10 $ SBC | BaseScan |
claude-research-agent/1.2 | Base | 0,10 $ SBC | BaseScan |
e2e-test-agent | Base | 0,10 $ SBC | BaseScan |
e2e-test-agent | Solana | 0,10 $ SBC | Solscan |

Este es mi panel de administración. Siete mensajes. Base y Solana. Cada uno se liquidó en la cadena antes de aparecer.
Enviarme un mensaje
Si estás desarrollando un agente, el punto final es POST benmilne.com/contact/send. Está documentado en la especificación OpenAPI y en agents.md.
Envía un POST sin encabezado de pago y el servidor devolverá un 402 con toda la información necesaria. La biblioteca de cliente x402 se encarga de la firma y de los reintentos a partir de ahí. El precio es de 1 SBC en Base y Solana. Si incluyes una URL de callback, podré responder en esa URL en el futuro.
Lo que he aprendido
La respuesta 402 es una factura legible por máquina. El agente no necesita interfaz de usuario. Necesita un precio, una dirección de activo y una red. Firma, paga y vuelve a intentarlo.
Intenté añadir compatibilidad con «USDC» a través de facilitadores de la comunidad que se anuncian como «sin claves». Ninguno de ellos funcionaba sin permisos. Uno requería el registro de la dirección. Otro tenía incompatibilidad de versiones. SBC, a través de The Stable Coin Company, fue el único facilitador que funcionó sin necesidad de ninguna configuración. Sin claves, sin cuentas, sin registro. Eso es importante si quieres que los agentes puedan pagar sin que un humano tenga que configurar nada primero.
Otra cosa que también me sorprendió: tanto MetaMask como Phantom seguían ocultando el SBC en mi monedero, incluso después de haberlo aprobado varias veces. Añadía el token, confirmaba la transacción, comprobaba mi saldo y el activo volvía a desaparecer. Esto ocurrió repetidamente durante las pruebas. No siento más que respeto por ambos equipos, pero tener que indicarle a mi monedero, en mi propio dispositivo, que quería utilizar mi propio activo de un emisor regulado, una y otra vez, me pareció ridículo. Internet es enorme. Los monederos deberían confiar en las decisiones que sus usuarios ya han tomado.
El código que utilicé para esto es de código abierto y eres libre de hacer lo que quieras con él, siempre y cuando MetaMask o Phantom no quieran influir en lo que hagas.