RAP Assurance (Reddi Agent Protocol Assurance) is an open, integration-first receipt and conformance layer for paid MCP/API and agent work.
Local/offline SDK primitives; not production/mainnet/live settlement evidence.
Payments prove transfer; RAP Assurance proves paid work.
Primary link: agent-protocol.reddi.tech
Case study. Status and evidence as of 2026-10-14 (UTC). Checked by the author against RAP's public claim boundary at a pinned commit, linked below.
What changed
A paid agent or API call ends with a payment record. That record can tell you a transfer happened. It cannot tell you whether the work was done to the terms you asked for. Reddi Agent Protocol (RAP) starts from that gap. RAP Assurance binds the work terms, the buyer's policy, a reference to the payment proof, the evidence, the attestation outcome, the replay metadata and reputation inputs together, so a builder can verify what happened around a paid workflow.
RAP's own boundary document states the limit of "proves" in plain terms. It says the claim must not extend to "payment evidence proves work quality, trust, reputation, settlement finality, or dispute outcome by itself". The record binds the pieces so you can check them. It is not a guarantee that the work was good.
What the record holds
RAP's receipt and policy definition describes ReddiReceipt v1 as "a protocol record, not a wallet receipt". Here is how some of its required fields line up with the questions a buyer asks after paying:
| Question after paying | Where the receipt records it |
|---|---|
| Which job, from which source, by which specialist? | job, source, specialist |
| What was asked, and what came back? | requestHash, responseHash |
| Which payment is this about? | payment (network, asset, amount in the asset's smallest unit, and paymentProofRef) |
| Was this spend allowed under my policy? | policyDecision (reddi.policy-decision.v1: allowed, reasonCodes, approvalState) |
| Where is the evidence? | evidenceRef |
| What attestation state was recorded? | attestationStatus: not_requested, pending, attested, failed or rejected |
This is a selected-field summary, not the complete required receipt schema; an attestation status is recorded metadata, not proof that someone checked output quality.
Receipts must not contain wallet key material, provider credentials, bearer tokens, cookies, raw auth headers, seed phrases, API keys or private customer data, and the conformance suite includes a check that rejects credential-shaped metadata.
Discover, decide, prove
RAP's Discover / Decide / Prove specification separates three stages. Discover asks what exists and where its metadata came from. Decide asks whether this buyer may use this source under this policy, budget and rail. Prove asks what happened and whether it can be verified later. The specification says discovery relevance is only a discovery signal, never trust, safety, budget, payment, invocation or publication approval; Decide gates must fail closed, and a rejected workflow must not emit Prove artifacts. This is the documented contract, not evidence of global runtime enforcement.
Why it mattered
If "paid" is allowed to stand in for "done", nobody checks the second thing. An agent that pays a specialist leaves behind a payment record and an output. Without a bound record there is nothing that ties that payment to the terms, the policy that allowed it, the evidence for the output and whoever attested to it. That is an argument, not a measurement, and it is the reason RAP Assurance exists.
RAP Assurance is positioned as complementary to payment and agent-discovery standards and products such as x402, MPP/Stripe-style machine payments, AP2, MCP Registry, A2A, AGNTCY/OASF, Pay.sh/PayAI and Solana/AUDD adapters. Those systems can prove or route payment and discovery; RAP Assurance records the paid-work lifecycle around them. Naming them is ecosystem context. It does not mean partnership, endorsement or a live integration.
What failed
Our own public copy overclaimed. Before 2026-09-30, RAP's public copy included wording the boundary now forbids. RAP's pull request 654 changed 121 files. According to its description it rewrote the landing page, navigation (the "Marketplace" label became "Directory"), about 30 app routes, the README and the whitepaper, and it removed or qualified marketplace, payment-facilitator, custody and escrow, take-rate, live settlement, and production and mainnet wording. It also labelled the scripted generation traces as simulated, with no transaction ids or Explorer links. A companion post covers the gate that was added to keep that wording from coming back.
A recorded devnet flow can no longer be replayed. The judge replication guide ends its registration walkthrough with a limitation: fresh CLI registration against the recorded Quasar deployment "is no longer replicable". The deployment predates a rework of how jobs are bound, and RAP's configuration records it as submissionReady: false. The recorded transactions remain as historical devnet evidence that can still be checked on a block explorer. The README adds that Quasar is frozen as historical experimental evidence and retired from product and production critical paths.
No verified v0.1.0 SDK publication milestone is established by this check. At 21:57 UTC on 2026-10-14, anonymous requests for the exact public npm versions @reddi/agent-protocol@0.1.0 and @reddi/x402-solana@0.1.0 returned HTTP 404, and GitHub returned HTTP 404 for the exact v0.1.0 tag and release. Local validation is not publication evidence. These dated observations do not establish a verified v0.1.0 package release.
Evidence
- The central message and the boundary. RAP's public claim boundary states the central message, what the repository can claim, and what public copy must not claim yet.
- The receipt shape. Receipt and policy decision v1 defines the fields in the table above.
- The stage model. Discover / Decide / Prove boundaries.
- The limitation. The judge replication guide and the README for the Quasar status.
- The site. agent-protocol.reddi.tech loads and states the central message. It is a public demo site, not a mainnet deployment claim.
- The pull request. Pull request 654, merged 2026-09-30.
Claim boundary
What we say, at or below RAP's own wording:
- Local/offline SDK and package primitives for receipt envelopes, policy decisions, payment-reference handling, evidence binding, replay fixtures and conformance checks.
- x402/Solana helpers that parse, gate and verify explicit proof material. The AUDD/SPL path is proof, payment-plan or read-only observation metadata, unless a separately approved live rail lands.
- A local-first MCP bridge and demos that disclose dry-run, Surfpool/local or recorded devnet boundaries before any spend or invocation claim.
What we do not say:
- That RAP Assurance is a broad agent marketplace, app store, generic or hosted runtime, wallet or action toolkit, payment facilitator, custody product or escrow provider.
- Production readiness, mainnet readiness, live AUDD/Solana settlement, unreviewed deployment, legal or compliance approval, or a completed security audit.
- That payment evidence proves work quality, trust, reputation, settlement finality or dispute outcome by itself.
- That this post establishes a verified v0.1.0 package-release milestone.
How to inspect or reproduce
The local path needs no wallet, RPC endpoint, hosted service, provider key or payment. Per RAP's README:
git clone https://github.com/nissan/reddi-agent-protocol
cd reddi-agent-protocol
git checkout cf0807688c3ef90457f69ac29c50f9519d3f40a0 # the commit this post was checked against
npm install
npm run check:conformance:public
At that commit it finishes with OK: all public conformance areas passed (offline, deterministic, no-spend) and eight conformance areas plus the packed-artifact guard (nine PASS summary rows), including receipt-shape, policy-decision-shape, evidence-binding and secret-leakage-rejection. A later commit may differ, so check the commit you are on. The recorded devnet transactions in the judge guide are historical evidence only, and we did not re-run its network verifier for this post. Dependency installation may use the registry; the conformance execution is offline and no-spend after setup.
What we learned
- Separate the claim "money moved" from the claim "work was done to terms". Most failures of trust in paid agent work live in the space between them.
- A record that binds terms, policy, payment reference, evidence and attestation is more useful than any one of them, and it is also easier to overclaim. Keep the sentence about what it does not prove next to the sentence about what it does.
- Write down what you cannot replay anymore. A recorded flow that no longer runs is still evidence, but only if the post says it is historical.