deadchannel & Hosaka

Dos servicios que venden a agentes de IA a través de x402, pagados por llamada en USDC. Sin registro, sin clave de API, sin suscripción: un agente llama, paga y recibe una respuesta.

Hosaka: datos de empresa para agentes

Disponible como servidor MCP, por lo que cualquier cliente MCP puede comprarle directamente:

npx -y hosaka-mcp

{
  "mcpServers": {
    "hosaka": {
      "command": "npx",
      "args": ["-y", "hosaka-mcp"],
      "env": { "HOSAKA_PRIVATE_KEY": "0x…" }
    }
  }
}

HOSAKA_PRIVATE_KEY es una cartera con un poco de USDC en Base. Cuatro herramientas a cuatro precios, para que una pregunta barata nunca pague por una respuesta cara:

Por qué vale la pena el expediente. Una empresa demuestra que es dueña de su dominio ante cada producto SaaS que compra colocando un registro de verificación DNS, y autoriza a cada remitente que utiliza en su registro SPF. Esas dos listas son un historial de compras que la propia empresa publicó.

Preguntar por figma.com devuelve Anthropic, OpenAI, Adobe, Atlassian, MongoDB Atlas, Greenhouse, Docusign, Stripe, Notion, Dropbox y Zendesk, cada uno con el registro exacto que lo demuestra, para que el comprador pueda comprobar en lugar de confiar.

Las huellas de página requieren un script cargado o un host de CDN, nunca una mención: un sitio que muestra el logotipo de un proveedor entre sus integraciones no es un sitio que lo utilice.

En vivo en hosaka-agents.vercel.app.

Related MCP server: techstack-detective-mcp

deadchannel: un oráculo de riesgo para endpoints x402

Dale una URL y le dice a un agente si ese endpoint está vivo, tiene un precio honesto y es seguro llamarlo, sin gastar ni un céntimo.

Aproximadamente el 17 % de los endpoints x402 sondeados están muertos o son trampas, y la capa de descubrimiento de Bazaar no ofrece clasificación, calidad ni señal de reputación según su propia admisión. Un agente que elige de ese catálogo está adivinando con dinero real.

Qué comprueba

Cada veredicto proviene de respuestas 402 no pagadas, que es lo que lo hace lo bastante barato como para ejecutarlo en todo un catálogo.

Veredictos: live, degraded, trap, testnet, dead, unknown, más una puntuación de riesgo acotada de 0 a 100.

Uso

Requiere Node 22+. No hay dependencias en tiempo de ejecución: los tipos se eliminan de forma nativa, por lo que no hay paso de compilación ni nada que auditar salvo este repositorio.

node src/cli.ts https://x402.org/protected
node src/cli.ts --quiet --samples 5 url-a url-b url-c
node src/cli.ts --json url > verdict.json

El código de salida es distinto de cero cuando algún objetivo es trap o dead, por lo que se integra en CI como protección contra el envío de un agente apuntando a un endpoint defectuoso.

TESTNET   risk 80   $0.01  355ms p99  https://x402.org/protected
  x network-mainnet   Only testnet networks offered (base-sepolia, solana-devnet).
                      This endpoint cannot accept real value.
  ! schema-advertised No input or output schema. An agent has to pay before it
                      can find out what it gets back.

Primer escaneo completo del catálogo: 20 de agosto de 2026

node src/scan.ts --live 150 extrae todos los recursos que publican los facilitadores públicos de Bazaar y los audita. Resultados sobre 14 979 recursos:

Precio medio de $0.01, rango de $0 a $1000, 316 927 llamadas pagadas en 30 días.

El catálogo está en mejor forma de lo que sugiere el folclore. Lo que no está es distribuido uniformemente: tres direcciones listan 2750 recursos entre ellas y reciben una de cada ochenta llamadas, lo que las hace aproximadamente 15 veces sobrerrepresentadas en relación con la demanda que atienden. El tamaño del catálogo no es profundidad del catálogo.

Una corrección y la salvaguarda contra su repetición

Una versión anterior de esta tabla afirmaba que el 89,8 % del catálogo no publicaba etiquetas. Eso era incorrecto. El cargador solo leía extensions.bazaar.tags, mientras que la mayoría de los editores colocan las etiquetas en la raíz del elemento: la cifra real es del 40,9 %.

El error sobrevivió a la revisión porque nada verificaba el recuento positivo. Una comprobación que solo cuenta lo que falta no puede distinguir "los editores omiten esto" de "estamos mirando en el lugar equivocado". test/catalog.test.ts ahora cuenta manualmente las etiquetas en las tres ubicaciones conocidas en un fragmento capturado de 200 elementos del catálogo en vivo y verifica que el cargador coincida exactamente, en ambas direcciones.

Notas del campo

Construido contra endpoints en vivo, no solo contra la especificación:

• v2 mueve los requisitos de pago a una cabecera payment-required en base64 y deja el cuerpo como {}. Un analizador que solo lea el cuerpo marcará el endpoint de referencia oficial como muerto.

• v2 envía identificadores de red CAIP-2 (eip155:84532, solana:EtWTRA…) donde v1 enviaba nombres amigables. Ambos están activos simultáneamente.

• v2 renombra maxAmountRequired a amount y eleva los metadatos compartidos de resource a la raíz de la carga útil.

• Varios servidores omiten el x402Version de nivel superior que todas las implementaciones de referencia envían, y algunos anidan accepts[] un nivel más profundo de lo documentado. Ambos se analizan y se notifican como advertencias en lugar de rechazarse.

• La mayoría de los recursos son POST. Sondearlos con GET devuelve 404/405, lo que se parece exactamente a un endpoint muerto: puso nuestra primera tasa de muerte por sonda en vivo en el 25 % cuando la cifra real es del 2,7 %. El verbo ahora proviene del catálogo, con un reintento POST cuando se desconoce. Cualquier índice x402 que informe una alta tasa de muerte merece que se compruebe esto.

• Los metadatos de descubrimiento están dispersos. La especificación coloca serviceName/tags en el objeto ResourceInfo, el catálogo CDP los aplana en la raíz del elemento, y una minoría los anida bajo extensions.bazaar. Lee una ubicación y subestimarás a la mitad.

• Existen raíles intermediarios. Los recursos de AWS Marketplace nombran al beneficiario con un URN bajo una red aws:base en lugar de una dirección de cadena. Eso es legítimo, pero los fondos van al intermediario, por lo que se informa como advertencia en lugar de puntuarse como pago no válido.

Venta

El servicio vende su propia comprobación a través de x402. src/server/ implementa el lado vendedor del transporte HTTP v2: PAYMENT-REQUIRED de salida, PAYMENT-SIGNATURE de entrada, PAYMENT-RESPONSE de vuelta, en el flujo de autorización: verificar, ejecutar el recurso y luego liquidar.

No interviene ninguna clave privada. Un vendedor declara dónde debe aterrizar la liquidación; el comprador firma y el facilitador transmite. La dirección de pago es, por tanto, información pública y vive en deadchannel.config.json, donde cualquiera puede auditarla, en lugar de en un panel donde nadie puede.

La liquidación solo se ejecuta después de que la sonda haya producido un resultado, por lo que un fallo de nuestro lado no le cuesta nada al comprador.

GET  /             service card, free
GET  /health       liveness, free
GET  /facilitator  proves credentials are accepted, free, moves no money
POST /probe        the check, $0.001 in USDC on Base

GET /facilitator existe porque una credencial incorrecta de otro modo permanece invisible hasta que alguien intenta pagar, y el primero en descubrirlo sería un cliente.

En vivo

El servicio está desplegado en https://deadchannel.vercel.app, vendiendo en la red principal de Base a $0.001 por llamada y liquidando a través del facilitador de Coinbase.

Primer pago liquidado: 0x6ac4a22c, bloque 50230005, 20 de agosto de 2026. El gas lo pagó el facilitador, no el comprador: en x402 el comprador solo firma, por lo que una cartera que solo contenga USDC puede pagar.

npm run validate vuelve a ejecutar las 25 comprobaciones previas que Bazaar aplica antes de indexar un recurso e informa si el listado está actualmente activo. No necesita clave y no mueve dinero.

resource : https://deadchannel.vercel.app/probe
valid    : true
accepted : accepted
checks   : 25/25 passed
indexed  : active=true

Hosaka

Una segunda tienda en la misma dirección de pago, que vende datos de empresas a agentes.

POST /lookup    $0.01   domain age, registrar, mail and DNS provider, DMARC, HTTPS
POST /dossier   $0.07    every third-party vendor we can prove, with the proof

En vivo en https://hosaka-agents.vercel.app, liquidando en la red principal de Base.

Los perfiles se ensamblan a partir de cuatro fuentes que no necesitan clave ni proveedor: DNS sobre HTTPS, el registro RDAP, el protocolo de enlace TLS y la página de inicio. El coste por perfil es cero: el margen está en el ensamblaje.

La parte interesante es la detección de proveedores. Una empresa demuestra su propiedad ante cada producto SaaS que compra colocando un registro de verificación DNS, y autoriza a cada remitente que utiliza en su registro SPF. Esas dos listas son un historial de compras que la propia empresa publicó. Cada afirmación lleva el registro que la demuestra, para que el comprador pueda comprobar en lugar de confiar.

Cómo usarlo desde Claude o ChatGPT

La búsqueda de Bazaar ignora la consulta y clasifica por pagadores únicos, por lo que una tienda nueva es invisible allí independientemente de la calidad. MCP es el canal que funciona desde el primer día: el agente ya está en un cliente que lo habla.

{
  "mcpServers": {
    "hosaka": {
      "command": "node",
      "args": ["/absolute/path/to/src/hosaka/mcp/server.ts"],
      "env": { "HOSAKA_PRIVATE_KEY": "0x…" }
    }
  }
}

El comprador aporta su propia cartera: la clave firma el pago localmente y nunca abandona la máquina. Sin ella, las herramientas dicen qué falta en lugar de fallar a mitad de conversación.

Desarrollo

npm install     # typescript only, for typechecking
npm test        # 18 tests, no network required
npm run typecheck

Licencia

MIT