Skip to main content
Every agentic payment protocol answers how an AI agent pays. None of them, on their own, answer how you prove (years later, offline, to a supervisor) that the payment was screened, authorised, and settled correctly. That proof is the receipt layer, and it is where AlgoVoi sits across the whole ecosystem. AlgoVoi issues deterministic, recomputable, offline-verifiable receipts for x402, AP2, A2A and MPP, all anchored on one shared JCS canonicalisation substrate so that a receipt emitted under any protocol re-verifies byte for byte at year N, independent of AlgoVoi.

Why a receipt layer, across all four protocols

The agentic-payments ecosystem is converging on four protocols: x402, AP2, A2A and MPP. They differ in how an agent is charged (per request, per mandate, per agent-call, per method) but share one unmet requirement: a portable, verifiable record of the compliance and settlement decision that outlives the session that produced it. A receipt layer is valuable only if it holds three properties:
  • Deterministic. The same logical decision serialises to the same bytes everywhere. AlgoVoi pins JCS, RFC 8785 as the canonical preimage form.
  • Recomputable. Anyone can re-derive the hash from the retained bytes, with no dependence on an out-of-band rule registry, via an in-band canon_version.
  • Offline-verifiable and no PII. Verification needs no live call to AlgoVoi, and the receipt carries categorical outcomes, not customer data. See the compliance receipt format and receipt verifier.

One substrate, every protocol

ProtocolWhat it charges forAlgoVoi receipt
x402per HTTP request (HTTP 402)compliance receipt at admission, settlement attestation on-chain
AP2per signed mandatemandate-bound compliance receipt plus settlement attestation
A2Aper agent-to-agent taskpayment-gated task receipt on the same substrate
MPPper JSON-RPC method or MCP tool callper-method compliance receipt
All four resolve to the same receipt grammar over the same canonical bytes. The action_ref primitive, SHA-256( JCS( { agent_id, action_type, scope, timestamp_ms } ) ), binds the agent, the action, and the settlement into one recomputable anchor regardless of which protocol carried the payment.

How a receipt is proven

  1. The gateway screens the incoming request (sanctions / PEP / AML, bring-your-own provider) and emits a categorical ALLOW / REFER / DENY compliance receipt.
  2. The receipt is canonicalised under JCS RFC 8785 and signed (RFC 9421, with a post-quantum option via the PQC substrate).
  3. On settlement, a settlement attestation chains the on-chain transaction to the same action_ref.
  4. Any party recomputes the canonical bytes and verifies the signature offline, at any later date, with the open receipt verifier.

Standards backing

The substrate is specified in AlgoVoi-authored IETF Internet-Drafts and cross-validated byte for byte across eight independent JCS implementations in eight languages: See authorship and provenance and the x402 document index for the full record.

Next