Skip to main content

What is MPP

The Method Payment Protocol is an IETF-flavoured spec for attaching prices to JSON-RPC methods and MCP tools. Where x402 paywalls HTTP endpoints, MPP paywalls methods. That makes it the natural fit for Model Context Protocol servers and structured RPC services. AlgoVoi is registered in the public MPP services catalogue at mpp.dev and can be discovered programmatically by MPP clients. The live server entry is also indexed on MPPScan.

Verifiable receipts for MPP

Every MPP method call AlgoVoi prices produces a deterministic, offline-verifiable per-method receipt on the shared JCS canonicalisation substrate: a categorical ALLOW / REFER / DENY compliance receipt at admission and a settlement attestation on-chain, bound by the action_ref primitive. Anyone can recompute the canonical bytes and verify the signature years later with the open receipt verifier, with no live call to AlgoVoi and no customer PII. See Agentic Payment Receipts for how this works across x402, AP2, A2A and MPP.

When to use MPP

Monetised MCP tools

Sell access to a database.query or web.scrape tool inside an MCP server.

JSON-RPC paywalls

Charge per eth_call shadow on your archive node, per getBlock on your indexer.

Method-level pricing

Different prices for read versus write methods on the same service.

Agent-discoverable services

AI agents browsing the MPP registry and paying to use any service that fits.

How MPP differs from x402

Both protocols speak the same Authorization: Payment scheme on the wire. AlgoVoi accepts either on the same gateway.

AgentCash

AgentCash is the reference CLI client for MPP over Tempo mainnet. It holds a USDCe wallet, handles the full challenge-pay-retry loop, and needs no API key or configuration to call any AlgoVoi-hosted MPP resource.

Discover and call with one command

Deposit funds

A successful payment returns a signed JWT receipt in the response body:

Per-tenant discovery spec

Each tenant that has enabled public MPP access exposes a machine-readable resource list:
AgentCash and MPPScan can use this to enumerate all payable resources for that merchant.

Keyless public route

AlgoVoi supports a keyless public MPP route — no X-Tenant-Id or X-API-Key required. The payment proof is the auth.
Tenants must opt in to this route (operators set mpp_public_enabled in the dashboard). When a tenant is not enabled or a resource doesn’t exist, the response is a cloaked 404 regardless of the reason.

Quickstart

1. Register your service

Define a service entry that points at your MPP-paywalled methods. AlgoVoi can register the entry on mpp.dev for you, or you can self-publish. Service definitions live in schemas/services.ts upstream. AlgoVoi’s own entry is published there as the canonical reference. See PR #556.

2. Issue a challenge

Client calls a paid method without payment. Server returns a Challenge:

3. Pay and present credential

Client pays on-chain, builds a Credential referencing the tx, and retries:
AlgoVoi verifies the credential, marks the payment consumed, and forwards the call.

Per-method pricing

A single MPP service can charge different prices for different methods:

Chain support

All 7 chains are supported. Each chain maps to a specific MPP method string and methodDetails shape per the paymentauth.org draft specifications. Configure the chain per-tenant in the dashboard; the gateway emits the correct challenge automatically.

Network reference

Algorand, VOI, and Hedera are not yet in the paymentauth.org catalogue. AlgoVoi implements custom methods for each, following the same request/credential shape as stellar (CAIP-2 methodDetails.network, push-mode txId credential).

Challenge example — Solana

Decoded request object:

Credential shapes by method

For AgentCash (Tempo mainnet), the CLI handles the full challenge-pay-retry loop automatically — see AgentCash above.

Subscriptions — intent="subscription"

In addition to per-call charges (intent="charge"), MPP supports subscription intent — a one-time authority tx that grants AlgoVoi standing permission to pull a fixed amount each period.

How it differs from per-call charges

Subscription challenge

When a resource is configured for subscription billing, the gateway returns a 402 with subscription fields:
The agent signs an on-chain authority tx, then re-submits with Authorization: Payment. AlgoVoi verifies the authority tx inline and executes the first-period charge on chain before returning (draft-payment-intent-subscription-00 §Activation L396-407). Activation succeeds only when the first pull is broadcast-accepted; the response carries status: "active", a base64url subscriptionId, a first_pull_tx_id, and a Payment-Receipt header. Clients may include an Idempotency-Key header on retries to get the cached response instead of a replay rejection — see Recurring payments — Idempotency. On successful activation the gateway returns:
The subscriptionId is base64url-no-padding per draft-payment-intent-subscription-00 §Subscription Identifier; internally it remains a 16-byte UUID, so it round-trips losslessly. first_pull_tx_id is the on-chain tx that collected the first period; a background finality monitor watches it until per-chain confirmation depth is reached and flips the subscription to status: "revoked" if the tx is orphaned before finality. If the first-period charge can’t be collected (insufficient allowance, wallet balance, etc.) the gateway returns 402 Payment Required rather than activating — the agent retries with a fresh challenge after resolving the cause. A facilitator-side timeout returns 504.

Subscription routes

Lifecycle

Once active, AlgoVoi’s pull reaper fires every 120 seconds and executes each subsequent period’s pull autonomously (the first period was already charged at activation). The agent receives no further prompts. See Recurring payments — MPP subscriptions for the full lifecycle, wire format, and resource setup details.

Audit trail & B2 retention

Every MPP payment — regardless of which route or client is used — is recorded in the payment_ledger table and shipped to Backblaze B2 Object Lock storage. Both paths converge on the same internal function before any response is returned.

Hash chain

Each PaymentLedgerEntry row receives three tamper-evidence fields at insert time: The canonical payload locked into each hash includes: tenant_id, resource_id, tx_id, chain, asset_id, amount_microunits, verified_at, payer_address, and status. These fields cannot be altered post-insert without breaking the chain.

B2 Object Lock shipping

A background reaper (running every ~5 minutes) batches new chained rows and ships them to B2:
Each .ndjson file contains the full canonical payload for every row in the batch, including content_hash and prev_hash, so external auditors can independently recompute and verify the chain. Files are written in COMPLIANCE mode Object Lock — immutable and undeletable for 7 years.

What this means for your integration

  • Keyless (AgentCash) payments: the payer_address of the AgentCash wallet is captured in the B2 record at the moment of payment. GDPR erasure after 90 days applies to the live database copy; the WORM copy is permanent per UK MLRs Reg 40.
  • Key-authenticated payments: same guarantee — the calling tenant and the on-chain tx_id are cryptographically bound to the tenant’s tenant_id in the chain.
  • Dispute resolution: tenants can request the B2 batch files for any time range from [email protected]. The batch SHA-256 is recorded in audit_chain_shipments for cross-reference.
  • Regulatory retention: minimum 5 years per UK MLRs Reg 40; AlgoVoi retains for 7 years (aligned with HMRC standard).

See also

  • x402 for HTTP endpoints
  • AP2 for Google’s mandate-based agent commerce
  • A2A for x402 over the Agent-to-Agent transport
  • Tempo chain for USDCe TIP-20 details
  • AlgoVoi on MPPScan — live server entry and resource index