Provides on-chain delivery receipts on Solana, enabling agents to issue, verify, and retrieve tamper-evident proof-of-delivery receipts anchored to a public PDA.
🔎 Early access (2 slots): I'll manually inspect your x402 endpoint's payment-to-delivery path and send you a conformance report within 24h — $9/$19. Details: https://x402-endpoint-inspection.app.workbuddy.host/
ReceiptRail is an on-chain delivery-receipt service for x402 AI-agent payments on Solana: after a settlement, sellers anchor a SHA-256 digest of the delivered content plus the settlement reference into a public PDA. Anyone — the buyer agent, an auditor, a regulator — can independently verify what was delivered, without trusting the vendor, the buyer, or any API we operate.
Surface | Entry |
MCP endpoint (streamable-http) |
|
Official MCP Registry |
|
npm (stdio MCP bridge) |
|
Agent Card / SKILL.md / llms.txt |
|
Pricing (0.001 USDC/receipt via x402) | |
Tools |
|
Keywords for agent discovery: x402 receipt, x402 escrow, delivery receipt, proof of delivery, Solana, USDC, MCP, AI-agent payments, verifiable settlement, receipt verification.
AgentToll is the delivery-receipt protocol behind ReceiptRail. A vendor pins the SHA-256 digest of a report's exact bytes into a public PDA account on-chain. Anyone can independently recompute the digest from the delivered file and compare it against the chain, without trusting anyone.
"Don't trust what we say. Run the command." Every capability claim in this README maps to a command in this repo and, where possible, a Solscan link on devnet.
Status: W1–W3 complete, independently audited (reports in audit/). Deployed on Solana devnet.
Program ID: 8ACN1KNEFXM2N2FMzxTfAzB1c3g5n47ZuhbPoUXPnCTp — view on Solscan
Receipt created by the recorded demo payment flow: delivery tx · payment tx
Honesty note: the demo uses test-USDC, a self-issued devnet mint with no real-world value. It is not real USDC. We say so everywhere, including in code output.
Related MCP server: x402 Payment Gateway MCP Server
Machine-to-machine payments (the x402 pattern) are becoming real: agents pay per API call. But after an agent pays, it holds no trustworthy proof of what it received. Receipts, invoices, or hashes served by the vendor itself are indistinguishable from fabricated ones. AgentToll moves that proof to a neutral public ledger: the digest is written once, is tamper-evident (same id + different digest is rejected on-chain), and is verifiable offline forever.
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.jsonExpected: JSON with "verdict": "PASS" and all five checks true (C1 ownership, C2 PDA derivation, C3 schema, C4 content binding, C5 freshness). Exit code 0. Then tamper with the file (add one byte) and rerun — C4 fails, exit code 1. That mismatch is the product.
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 JSONThe on-chain program enforces the anti-tamper rule at the ledger level: a PDA seeded by (vendor, report_id) can be created once; re-creating with the same digest is idempotent, with a different digest fails with DigestConflict. Overwrites are impossible, not just discouraged.
Requires Node.js 22+, a devnet-funded vendor keypair, and the deployed program above.
# 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 reportdemo/buyer-agent.mjs prints {payment_sig, receipt_tx, pda, verifier_verdict, checks} and exits 0 only if the spawned offline verifier passes all five checks.
Anchor 1.2.0, two instructions:
create_receipt(report_id, digest) — first call creates the PDA; same id + same digest is idempotent; same id + different digest → DigestConflict
verify_receipt(report_id, digest) — permissionless; emits a ReceiptVerified event
Build and test locally:
./build.sh # = anchor build --arch v0
cargo test --all # 8 litesvm tests, incl. DigestConflict & idempotencyEvery milestone was reviewed by an independent auditor that did not write the business code. Reports with command outputs and on-chain evidence:
audit/W1-2026-09-14.md — contract, 8/8 tests, devnet deployment
audit/W2-2026-09-14.md — offline verifier, tamper-detection e2e
audit/W3-2026-09-14.md — x402 flow, negative paths, idempotent replay
test-USDC is self-issued on devnet; it stands in for a real stablecoin. No real value.
The demo serves one report id on localhost; it is a protocol demo, not a hosted service.
The on-chain receipt binds report_id + digest; the payment signature is linked via the demo flow, not stored on-chain (the frozen W1 schema has no such field). See W3 audit §findings.
A professional third-party security audit is on the roadmap and has not happened yet.
This project was built for the Colosseum CWF hackathon. Per the rules, we disclose pre-existing development: t3n-recon-agent and z-tenant-recon — a TEE-based prototype implementing the same anti-tamper digest logic (same-id-different-digest rejection, independent verifier), from which the on-chain design was ported. All AgentToll commits, tests, and deployments happened during the competition window (first commit: 2026-09-14).
中文说明见 README.zh-CN.md。
Fetch full receipt details: digests, checks, outcome, amount, buyer, seller, timestamp, PDA. Look up by receipt_id, or by x402_payment_ref (always works — the receipt lives on-chain). Read-only, no cost.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | No | Receipt id, e.g. r_abcdef1234567890 | |
| payment_ref | No | x402_payment_ref of the transaction (use this if receipt_id unknown; resolved on-chain) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states 'Read-only, no cost' and 'always works — the receipt lives on-chain', which informs the agent about safety and reliability. It does not mention failure modes or return format details, but for a read-only tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states what is returned, the second explains lookup methods and safety. Critical information is front-loaded and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the returned fields, both lookup methods, and discloses read-only status. With no output schema, this is sufficient for an agent to know what to expect. Minor gaps like precedence when both parameters are provided are not addressed, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters have descriptions. The description adds value by explaining that payment_ref is the more reliable lookup method and provides an example format for receipt_id. This goes beyond the schema's basic type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Fetch) and resource (full receipt details) and enumerates the specific fields returned (digests, checks, outcome, amount, buyer, seller, timestamp, PDA). This clearly distinguishes it from sibling tools issue_receipt and verify_receipt, which focus on creation and verification respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear lookup guidance: use receipt_id or x402_payment_ref, and explicitly notes that payment_ref always works because the receipt lives on-chain. It does not explicitly contrast with siblings, but the purpose is distinct and the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Anchor a SHA-256 digest of delivered content plus the x402 settlement reference on Solana. Returns a permanent, publicly verifiable receipt (poll until outcome === "settled"). Costs 0.001 USDC via x402; if x402_payment_signature is omitted, returns the payment challenge instead (pay 0.001 USDC to the service address, then call again with the payment tx signature).
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | No | Optional buyer identifier (wallet address) | |
| seller | No | Optional seller identifier | |
| x402_payment_ref | Yes | Unique reference for this transaction (1-128 chars) | |
| deliverable_digest | Yes | SHA-256 hex digest (64 chars) of the delivered content | |
| x402_payment_signature | No | Solana tx signature of the 0.001 USDC payment to the service address. Omit to receive the payment challenge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that it costs 0.001 USDC, requires x402 payment, and returns a payment challenge if signature omitted. However, it does not describe what happens on failure (e.g., insufficient payment, invalid digest), or the exact format of the challenge, though polling behavior is mentioned. Partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact two-sentence description that front-loads the core purpose and then explains the payment flow. Good use of parentheses. Slightly dense, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transactional tool with payment and multiple optional params, description covers the essential flow but misses failure scenarios, return structure details, and any rate limits. Given no output schema and no annotations, there is room for more, but the core usage is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a decent description. Description clarifies that x402_payment_signature is optional and its omission triggers challenge issuance, which adds value. But it doesn't elaborate on buyer/seller semantics beyond schema—acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'anchor', resource (SHA-256 digest + x402 settlement reference on Solana), and outputs a permanent publicly verifiable receipt. Differentiates from siblings: get_receipt retrieves, verify_receipt verifies, issue_receipt anchors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly explains when to use: to issue a receipt for delivered content after payment. It also specifies the two-step flow: omit signature to get challenge, then call again with signature. No alternatives mentioned but the usage context is clear and complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an AgentToll receipt against live Solana state: PDA owner must be the AgentToll program and the stored digest must match the receipt. Look up by receipt_id, or by x402_payment_ref (always works — the receipt lives on-chain). Read-only, no cost.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | No | Receipt id, e.g. r_abcdef1234567890 | |
| payment_ref | No | x402_payment_ref of the transaction (use this if receipt_id unknown; resolved on-chain) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: discloses read-only nature, no cost, on-chain verification logic, and the fallback lookup behavior. It does not state failure semantics (error vs. boolean result) or return format, which is a minor gap for a verify tool given zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: core verification logic front-loaded, then lookup methods, then a concise safety note. Every sentence earns its place and the most important information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers verification semantics and lookup well, but does not explain what the agent receives on success or failure, nor whether both parameters can be provided together. This is a meaningful gap for an MCP tool with no structured output contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well documented in the schema, so the baseline is 3. The description adds the nuance that payment_ref 'always works' and clarifies the relationship between the two lookups, adding marginal value beyond the schema but not compensating for anything missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (AgentToll receipt against live Solana state), then defines what verification means concretely: PDA owner must be the AgentToll program and the stored digest must match. This gives an agent a precise mental model and implicitly differentiates from siblings get_receipt (fetch) and issue_receipt (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear lookup guidance: primary key receipt_id, with payment_ref as the reliable fallback ('always works — the receipt lives on-chain'), reinforced by the schema's 'use this if receipt_id unknown.' However, it does not explicitly state when to choose verify_receipt over get_receipt, leaving the verify-vs-fetch decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_receiptissue_receiptverify_receiptThis server cannot be deployed
Score is being calculated.
On-chain x402 delivery receipts on Solana: hash-locked, verifiable proof of delivery.
Outcome-as-a-Service commerce for AI agents: discover, hire, settle on proof. Live on devnet.
Trust OS for service businesses — x402 MCP tools, Solana escrow, AI scoring
Solana Mainnet verification, intelligence, machine receipts, and agent logistics through MCP.