Open receipts for paid agent jobs
Receptum is an open receipt format for paid AI jobs. Each receipt binds the payment to SHA-256 hashes of the exact inputs and output — so the buyer, their agent and an auditor can check what was delivered without trusting your servers.
Live on testnets: signed receipts over x402 (Base Sepolia, Stellar, the XRP Ledger and Solana), seller-to-payout-wallet bindings, escrow on Arc, Arbitrum, Stellar (Soroban and claimable balances), the XRP Ledger and Solana (an immutable program), Receptum Verify plus an independent Python verifier — 30 published testnet receipts re-verify against the live chains.
Mainnet: after an independent audit.
Apache-2.0 · No token · Built on x402 · npm packages · Unaudited — testnet only
Paid via x402 · receipt anchored on Arc testnet
A real receipt from Base Sepolia testnet · settlement · anchor · verify it below
60-second explainer
Agents can pay. Their receipts don't say what they bought.
Jobs get regenerated and files get swapped, and disputes end in "our logs say otherwise."
Payment receipts prove money moved and a service answered — not which file it delivered. An agent needs that before it uses a result or releases money.
Your service prices it. The agent pays through the rail you already use.
Paid directly over x402 on Base, Stellar, XRPL or Solana, or held in escrow: the Receptum contract on Arc, Arbitrum or Soroban, the immutable Receptum program on Solana, or native XRPL and Stellar escrow.
Bind the payment to hashes of the inputs and the output, and commit the receipt hash on-chain. A binding signed by the payout wallet proves the seller controls it. Only hashes are published.
By the buyer, an evaluator, or when the review window closes. The receipt records which.
In escrow, no delivery by the deadline → the buyer reclaims the funds, no approval needed. A mismatched file is grounds to reject during the review window.
npm install @receptum/core On npm today
import { createReceipt, generateSellerKey, receiptHash, sha256File } from "@receptum/core"; const seller = generateSellerKey(); // keep its private key secret const receipt = createReceipt({ jobId: "render-8841", seller: { id: seller.did, name: "render.example" }, inputSha256: [await sha256File("source.mp4")], outputSha256: await sha256File("final.mp4"), payment: { rail: "x402:exact", network: "eip155:84532", asset: "USDC", amount: "250000", reference: "0x…" }, acceptance: { mode: "auto", reviewWindowSeconds: 259200 }, }); receiptHash(receipt); // the one value that goes on-chain
Pick a published testnet receipt, or drop your own receipt and the file it was issued for. Your browser checks the file, the seller's signature, that the seller controls the payout account, the payment on its rail and that the receipt hash is committed on-chain — the same checks and verdicts as the CLI. It says VERIFIED only if every one passes, and names what is missing otherwise. Every result starts with a TESTNET or MAINNET label, like the CLI: a testnet receipt is about test tokens only. Nothing is uploaded.
Published testnet receipts
Every receipt the SDK publishes as VERIFIED: x402 on Base Sepolia, Stellar, XRPL (XRP and an issued token) and Solana devnet, an x402-paid MCP tool, ReceptumEscrow on Arc and Arbitrum Sepolia, native XRPL escrows (crypto-condition, evaluator, TokenEscrow), Soroban and Stellar claimable-balance escrows, and the immutable Solana escrow program (buyer accepts, auto-release, evaluator accepts) — plus a tampered receipt and a refunded escrow, which must fail. All 30 published testnet receipts re-verify here with the verdicts the SDK expects.
Or verify your own
Or from a terminal: npx @receptum/verify live-receipt.json render.svg (the wrapper's anchor is checked automatically), or the independent Python verifier: python -m receptum_verify live-receipt.json render.svg.
Apache-2.0 code and the RRF v1 spec with test vectors. JCS-canonical (RFC 8785), Ed25519 seller signatures, so a receipt can ride alongside an x402 receipt or stand alone. No token, no fee to verify.
| Component | Status |
|---|---|
| RRF v1 spec + JCS test vectors, Ed25519 seller signatures | Live |
| x402 paid jobs and paid MCP tools with signed receipts | Live · Base Sepolia |
| Stellar, XRPL and Solana x402 payments with signed receipts | Live · Stellar, XRPL & Solana testnets |
| Seller ↔ payout account bindings (EVM, XRPL, Stellar, Solana) | Live · testnets |
| Receptum escrow contract (accept, reject, auto-release, refund) | Live · Arc & Arbitrum testnets |
| Soroban escrow contract (same flows, plus evaluator mode) | Live · Stellar testnet |
| Stellar claimable-balance escrow (USDC) + MEMO_HASH anchors | Live · Stellar testnet |
| XRPL native Escrow with crypto-conditions + memo anchors | Live · XRPL testnet |
| Solana escrow program, immutable (same flows, plus evaluator mode) + memo anchors | Live · Solana devnet |
| Receptum Verify (CLI + this page) | Live |
| Independent Python verifier, written from the spec alone | Live |
| npm packages (@receptum/*) | Live on npm |
| x402 extension proposal for input/output hashes | Drafted |
| Independent audit, then mainnets (plan published), 1.0 spec | Q1 2027 |
Yes — they prove a payment was made and the service responded. Receptum adds which output was delivered and for how much, and is designed to travel inside x402 receipts.
No. It proves which work was delivered. Quality is decided by buyer acceptance or an evaluator, and the receipt says which.
The whole system, on testnets: signed receipts for x402 payments on Base Sepolia, Stellar testnet, XRPL testnet and Solana devnet and for paid MCP tools; account bindings proving the seller controls its payout wallet (EVM, XRPL, Stellar and Solana); the Receptum escrow contract on Arc and Arbitrum testnets and on Soroban (Stellar testnet); the immutable Receptum escrow program on Solana devnet; native escrow on the XRPL and Stellar testnets (claimable balances); all 30 published testnet receipts re-verify against the live chains, each with its expected verdict; and Receptum Verify (CLI and this page) plus an independent Python verifier written from the spec alone. Install with npm install @receptum/core. Nothing is audited yet, so there is no mainnet support: mainnets come after an independent audit, and the 1.0 spec in Q1 2027.
The receipt settles the evidence instantly: both sides can prove the faulty file is exactly the one that was delivered, so nobody can claim it was swapped or edited. Sellers are paid in full on acceptance — no holdback by default. Late defects are covered by the seller's signed remedy terms in the receipt (for example "free re-render within 30 days"), an optional automated QA check before release, and a follow-up receipt for the fix that links to the original. Live in RRF v1
No. Receipts are pseudonymous: buyer and seller appear only as wallet addresses and the seller's public key — the same addresses already visible in the payment on-chain. The account binding links the seller's key to its payout wallet, nothing more. No names, emails or personal data, and the delivered work itself is never published, only its hash.
No. Payment is in stablecoins on existing chains.
Swiftleads AI, Inc., a team that has been building AI products for years: the LeadTracker AI business operating system, Swiftleads AI and Novacall AI, and the Agent Architects Skool community for people building AI agents. Receptum is led by Parvez Zoha (co-founder & CEO) with Samantha Guillen (co-founder & CMO) and developer Noman Hussein. We build and run AI agents for a living; Receptum is the open, chain-neutral record of paid agent work we wanted and couldn't find, and our own products will be its first integrations.
For companies that sell AI work by the job — video renders, dubbing, upscaling, transcription, research.
How the pilot works: we add Receptum receipts to one of your paid services with you, on a test network, free. You get a direct line to our engineers and credit in the open spec. We ask for a 30-minute call and honest feedback.
Get one email when Receptum 1.0 ships. Nothing else.
For grant committees: see the roadmap and the open-source repo.
Receptum