MPP compatibility phase 1: speak the Payment header envelope (charge intent)

[hellno]

Standalone follow-on; sequenced after #34 and #208. Created now (2026-07-07) to keep the MPP story visible; do not start before #34 lands.

Context (verified 2026-07-07)

MPP — the Machine Payments Protocol (Tempo + Stripe, spec at mpp.dev, built on the "Payment" HTTP authentication scheme proposed to the IETF) — is backwards-compatible with x402: the x402 exact flow maps directly onto MPP's charge intent, and on EVM both sign the SAME EIP-3009 transferWithAuthorization. Servers can emit both challenges in one 402 response (WWW-Authenticate: Payment alongside PAYMENT-REQUIRED) and accept either credential format. Sources: developers.cloudflare.com/agents/agentic-payments/mpp/ (back-compat statement), mpp.dev/mpp-vs-x402, github.com/tempoxyz/mpp-specs.

So once Deckard speaks x402 exact (#34), MPP charge interop is nearly free: the signature and the signing-time budget check are the identical code path — only the HTTP envelope differs.

Scope

Extend the agent-side client (#208) to also:

• parse WWW-Authenticate: Payment challenges,
• emit Authorization: Payment credentials,
• read Payment-Receipt responses,
  reusing the same daemon authorize+sign wire and budget ledger. No new signer code. Dep question (official Rust SDK tempoxyz/mpp-rs exists, typed Challenge/Credential/Receipt) is decided the Spike: x402 build shape — hand-rolled EIP-3009 vs x402-rs, and prove the fully-local facilitator loop #206 way: evidence first, hand-roll by default.

Non-goals

• MPP sessions (pre-funded escrow channels + signed off-chain voucher streams) — a different enforcement model than per-signature caps; revisit alongside the Tempo spike Spike: Tempo feasibility — resolve the type-2 vs 0x76 contradiction #102.
• Card rails (Stripe charge) — outside a self-custody wallet's remit.
• Tempo chain support (Spike: Tempo feasibility — resolve the type-2 vs 0x76 contradiction #102's territory).

Acceptance

The #208 client fetches a paid resource from an MPP-charge server fixture using the same policy/budget path as x402; the deny/budget behavior is byte-identical; docs explain MPP in plain words once ("MPP — a payment protocol agents use over HTTP; its one-time charges are compatible with x402").

[0xbrainkid]

This is a good place to keep the MPP/x402 bridge small. One practical test shape I would add: normalize both challenge envelopes into the same internal authorization record before signing, then assert the downstream budget/receipt path cannot tell whether the request arrived as PAYMENT-REQUIRED or WWW-Authenticate: Payment.

The normalized record probably wants these fields at minimum:

• scheme source: x402 or mpp-charge
• resource URL / route key
• rail, asset, network, recipient, and amount ceiling
• challenge digest, observed_at, and expiry/replay window
• signer policy id and budget ledger entry id
• expected receipt header/body digest after settlement

That gives you a clean fixture matrix: same EIP-3009 signing path, same deny cases, and different only at HTTP parse/emit boundaries. It also makes later agent-trust work easier, because an external verifier can inspect the payment decision without depending on either envelope format.

AgentFolio is open beta and SATP is RC-S6 / building in public, so I would frame this as interoperability evidence rather than a finished standard claim. Happy to compare notes if a tiny challenge-normalization example would be useful.