ReceiptRail

Emitir y verificar recibos de entrega x402 en cadena en Solana. Prueba de entrega bloqueada por hash, verificable de forma independiente, para pagos de agentes de IA: los compradores verifican sin conexión con cero confianza en el emisor.

GitHubPrueba este MCPPatrocinado

Servidor MCP alojado

npx add-mcp 'https://agenttoll-receipts.app.workbuddy.host/mcp'

Se instala en Claude Code, Codex, Cursor y más

Documentación

ReceiptRail (antes AgentToll) — recibos de entrega en cadena para x402

🔎 Acceso anticipado (2 cupos): Revisaré manualmente la ruta de pago a entrega de tu endpoint x402 y te enviaré un informe de conformidad dentro de 24 h — $9/$19. Detalles: https://x402-endpoint-inspection.app.workbuddy.host/

ReceiptRail es un servicio de recibos de entrega en cadena para pagos de agentes de IA x402 en Solana: después de una liquidación, los vendedores anclan un hash SHA-256 del contenido entregado más la referencia de liquidación en una PDA pública. Cualquiera — el agente comprador, un auditor, un regulador — puede verificar de forma independiente qué se entregó, sin confiar en el proveedor, el comprador ni en ninguna API que operemos.

⚡ Servicio en vivo (úsalo ahora)

Superficie	Entrada
Endpoint MCP (streamable-http)	`https://agenttoll-receipts.app.workbuddy.host/mcp`
Registro oficial de MCP	`io.github.xka0085-byte/receiptrail`
npm (puente MCP stdio)	`npx -y receiptrail-mcp`
Agent Card / SKILL.md / llms.txt	`/.well-known/agent-card.json` · `/SKILL.md` · `/llms.txt`
Precios (0.001 USDC/recibo vía x402)	https://agenttoll-receipts.app.workbuddy.host/
Herramientas	`issue_receipt` · `verify_receipt` · `get_receipt`

Palabras clave para descubrimiento por agentes: recibo x402, custodia x402, recibo de entrega, prueba de entrega, Solana, USDC, MCP, pagos de agentes de IA, liquidación verificable, verificación de recibos.

AgentToll es el protocolo de recibos de entrega detrás de ReceiptRail. Un proveedor fija el hash SHA-256 de los bytes exactos de un informe en una cuenta PDA pública en cadena. Cualquiera puede recalcular de forma independiente el hash a partir del archivo entregado y compararlo con la cadena, sin confiar en nadie.

"No confíes en lo que decimos. Ejecuta el comando." Cada afirmación de capacidad en este README corresponde a un comando en este repositorio y, cuando sea posible, a un enlace de Solscan en devnet.

Estado: W1–W3 completos, auditados de forma independiente (informes en audit/). Desplegado en Solana devnet.

ID del programa: 8ACN1KNEFXM2N2FMzxTfAzB1c3g5n47ZuhbPoUXPnCTp — ver en Solscan
Recibo creado por el flujo de pago de demostración registrado: transacción de entrega · transacción de pago

Nota de honestidad: la demostración usa test-USDC, un mint de devnet autoemitido sin valor en el mundo real. No es USDC real. Lo decimos en todas partes, incluso en la salida del código.

Por qué existe esto

Los pagos de máquina a máquina (el patrón x402) se están volviendo reales: los agentes pagan por llamada a API. Pero después de que un agente paga, no tiene prueba confiable de qué recibió. Los recibos, facturas o hashes servidos por el propio proveedor son indistinguibles de los fabricados. AgentToll mueve esa prueba a un libro de contabilidad público neutral: el hash se escribe una sola vez, es a prueba de manipulación (mismo id + hash diferente se rechaza en cadena) y es verificable sin conexión para siempre.

Verifica un recibo existente ahora mismo (sin participación del proveedor)

cd verifier && npm install && cd ..
node verifier/verify.mjs \
  --url https://api.devnet.solana.com \
  --vendor B7wGaKwEGAmNP7PEhqwFrvfCQPH4zwiE7FZNLoeB4naD \
  --report-id x402-demo-001 \
  --file demo/report-402.json

Esperado: JSON con "verdict": "PASS" y las cinco verificaciones true (C1 propiedad, C2 derivación de PDA, C3 esquema, C4 vinculación de contenido, C5 frescura). Código de salida 0. Luego altera el archivo (añade un byte) y vuelve a ejecutar — C4 falla, código de salida 1. Esa discrepancia es el producto.

Arquitectura

sequenceDiagram
    participant B as Buyer agent
    participant V as Vendor HTTP service
    participant S as Solana devnet
    participant C as Offline verifier
    B->>V: GET /report/x402-demo-001
    V-->>B: HTTP 402 + payment challenge
    B->>S: SPL transferChecked (test-USDC)
    B->>V: POST + X-Payment-Signature
    V->>S: getParsedTransaction, verify payment
    V->>S: create_receipt(report_id, SHA-256)
    V-->>B: report bytes + receipt metadata
    B->>C: Spawn verifier with local report
    C->>S: Read receipt PDA via public RPC
    C-->>B: C1-C5 PASS/FAIL JSON

El programa en cadena aplica la regla anti-manipulación a nivel del libro de contabilidad: una PDA sembrada por (vendor, report_id) puede crearse una sola vez; recrearla con el mismo hash es idempotente, con un hash diferente falla con DigestConflict. Las sobrescrituras son imposibles, no solo desaconsejadas.

Ejecuta la demostración completa de x402

Requiere Node.js 22+, un par de claves de proveedor financiado en devnet y el programa desplegado anteriormente.

# 0. install the single JS dependency set
cd verifier && npm install && cd ..

# 1. configure (bash example)
export AGENTTOLL_RPC_URL='https://api.devnet.solana.com'
export AGENTTOLL_KEYPAIR='/absolute/path/to/vendor-keypair.json'

# 2. create test-USDC mint, fund buyer (idempotent)
node demo/setup.mjs

# 3. start vendor (localhost:8787)
node demo/vendor.mjs

# 4. unpaid request must be refused
curl -i http://127.0.0.1:8787/report/x402-demo-001        # → HTTP 402

# 5. run the buyer agent: pay → receive report+receipt → verify 5/5
node demo/buyer-agent.mjs

# 6. forged payment signatures must be rejected
curl -i -X POST -H 'X-Payment-Signature: not-a-real-signature' \
  http://127.0.0.1:8787/report/x402-demo-001              # → HTTP 402, no report

demo/buyer-agent.mjs imprime {payment_sig, receipt_tx, pda, verifier_verdict, checks} y sale con 0 solo si el verificador sin conexión generado pasa las cinco verificaciones.

Programa en cadena (W1)

Anchor 1.2.0, dos instrucciones:

create_receipt(report_id, digest) — la primera llamada crea la PDA; mismo id + mismo hash es idempotente; mismo id + hash diferente → DigestConflict
verify_receipt(report_id, digest) — sin permisos; emite un evento ReceiptVerified

Compila y prueba localmente:

./build.sh        # = anchor build --arch v0
cargo test --all  # 8 litesvm tests, incl. DigestConflict & idempotency

Auditorías

Cada hito fue revisado por un auditor independiente que no escribió el código de negocio. Informes con salidas de comandos y evidencia en cadena:

audit/W1-2026-09-14.md — contrato, 8/8 pruebas, despliegue en devnet
audit/W2-2026-09-14.md — verificador sin conexión, e2e de detección de manipulación
audit/W3-2026-09-14.md — flujo x402, rutas negativas, reproducción idempotente

Alcance y limitaciones (léelo antes de confiar en cualquier cosa)

test-USDC es autoemitido en devnet; representa a una stablecoin real. Sin valor real.
La demostración sirve un id de informe en localhost; es una demostración de protocolo, no un servicio alojado.
El recibo en cadena vincula report_id + digest; la firma de pago se vincula mediante el flujo de demostración, no se almacena en cadena (el esquema congelado de W1 no tiene ese campo). Ver auditoría W3 §hallazgos.
Una auditoría de seguridad profesional de terceros está en la hoja de ruta y aún no ha ocurrido.

Trabajo previo divulgado

Este proyecto se construyó para el hackathon Colosseum CWF. Según las reglas, divulgamos el desarrollo preexistente: t3n-recon-agent y z-tenant-recon — un prototipo basado en TEE que implementa la misma lógica de hash anti-manipulación (rechazo de mismo-id-hash-diferente, verificador independiente), del cual se portó el diseño en cadena. Todos los commits, pruebas y despliegues de AgentToll ocurrieron durante la ventana de la competencia (primer commit: 2026-09-14).

Instrucciones en chino en README.zh-CN.md.