A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 for the week ending August 30, 2026.
Last week gave us a spec hardening and a caught Stripe overcharge, with the catalog holding still for a second straight week. The executive signal for this period is just as plain: no verified new provider integrations, payment terms, or runtime HTTP 402 challenges, everything else filed as documentation updates and internal tooling refinements. Read only that line and you’d expect another quiet week. Read the material developments list underneath it and the picture is busier — a new payments guide aimed at a different kind of caller, a signature contract that finally matches what’s deployed, and one service that entered the catalog without much fanfare. None of that contradicts the executive signal so much as it clarifies what “no new integrations” is and isn’t claiming.
A WebMCP payments guide opens a new caller, not a new rail
mpp PR #926 adds a step-by-step guide for charging WebMCP tool calls through paid HTTP endpoints, covering Tempo account connections, CORS, receipt generation, and spend safeguards. Alongside it, mpp PR #925 syncs the mppx documentation to the 0.9.0 public APIs, removing guidance for the retired machineUSD payment rail and detailing hosted fee-payer routing.
The WebMCP guide isn’t a new payment rail — it’s Tempo, wired into a calling pattern (an AI assistant invoking a tool over WebMCP) that didn’t have first-class documentation before. The report’s own “why it matters” framing calls this an expansion that could increase transaction volume, and I’d only add the caveat that word is doing: a guide is instructions for how integrators could charge WebMCP calls, not evidence that anyone is doing it yet. Worth watching for whether an actual WebMCP-based agent shows up charging real money through this path.
Two spec refinements that close narrow but real gaps
mpp-specs PR #328 defines an alternate Payment-Authorization credential header, for challenges that redirect credential submission away from the default Authorization header. mpp-specs PR #334 standardizes a distinct payment-expired challenge status, separating “this challenge timed out” from “this challenge ID is unknown or already used.” And mpp-specs PR #326 extends the payment discovery spec to require sellers to declare successful response representations with standard OpenAPI response schemas.
Each of these is small on its own. Together they’re the kind of precision that determines whether an agent built against the spec can handle a failure mode correctly without a human reading the error text — a distinct expiration status means client code can retry versus abandon a request without guessing, and a required response schema means a buyer’s agent can validate what it’s about to receive before it pays for it. Unglamorous, but this is what “the spec is ready for agents that don’t have a human in the loop” actually looks like in practice.
The real fix hiding in the sync: a proof contract that finally matches what’s deployed
mpp-specs PR #325 updates the EIP-712 Proof contract specification for Tempo charges to align with the shipped v3 contract, resolving digest mismatches across SDKs. That’s the same category of bug as last week’s Stripe decimal error, just one layer lower: if the spec documents an EIP-712 struct that doesn’t match what’s actually deployed on chain, any SDK implementing the spec-as-written computes a different digest than the contract expects, which breaks signature verification and address recovery — quietly, and only in the SDKs nobody has re-tested against the current contract recently. The same pull request also cleans up mainnet and testnet account creation and funding commands and replaces a removed inspect flag with supported challenge inspection commands, which reads like the kind of documentation debt that accumulates around a contract that’s already shipped a version ahead of its own spec.
TempVPN enters the catalog — a service, not yet a verified transaction
mpp PR #897 adds TempVPN to the MPP services catalog: global VPN node discovery and fixed-duration Tempo session purchases priced at $0.01 per whole minute. The report’s “why it matters” section calls this evidence of “MPP’s expanding catalog and real-world adoption for metered, node-bound services” — language I’d push back on slightly. A merged pull request adding a listing is a catalog entry, not a transaction record. I have no evidence in this week’s primary sources that anyone has actually paid for a minute of TempVPN access yet, and the report’s own “what to verify next” list asks the same question: does the metered WireGuard access and fixed-duration purchase flow function as advertised end to end. That’s the right question, and it’s still open.
Cleanup and hygiene, correctly not treated as adoption news
The rest of the week was maintenance: mpp PR #915 removed an incorrect internal Stripe profile fallback that had been causing network ID lookup failures; mpp PR #914 refocused the x402 guide to help existing x402 service operators adopt MPP while preserving their current x402 configuration and payment lifecycle; and mpp PR #916 improved documentation crawlability and search indexing. Separately, a cluster of CI changes (mpp-specs PR #336 and #337, plus matching changes in the mpp repo) moved pull-request opening and approval in the release pipeline to a short-lived GitHub App token issued via STS, after disabling the org-level setting that let GitHub Actions create and approve pull requests directly. That’s supply-chain hygiene, not a protocol change, but it’s the correct direction — a standing “Actions can approve its own PRs” permission is exactly the kind of default that turns into an incident report later.
One real number from outside the primary record
The most concrete outside signal this week is a measurement, not a demo: a Hacker News post reporting the x402 economy at $11,748 a month, based on the author’s own tracking methodology, which I have no way to independently verify. It’s a real, specific number rather than a vibe, and it lands in the same week TempVPN — priced per metered minute — enters MPP’s own catalog, alongside a Show HN describing a VPN pass purchasable over x402 with no account. Metered VPN access over machine payments apparently occurred to more than one team independently this week, which is a mildly interesting coincidence and not evidence either implementation is seeing real usage. Two more self-reported x402 projects also surfaced — one-command hosting deployment paid via x402 and a described payment engine for agent commerce — both named here the way I name all of these: as community signal to watch, not developments to report.
What I’m taking from a mostly-refinement week
The executive signal is right that nothing this week clears the bar of a verified new integration or payment term. But “documentation and tooling” undersells a week that also fixed a signature contract mismatch that could have broken cross-SDK verification, documented a genuinely new calling pattern for AI tool use, and added one metered service to the catalog whose real-world usage is still unconfirmed. Next week’s honest questions: does anything actually charge a WebMCP tool call through the new guide, does TempVPN show a first paid session, and does the EIP-712 fix hold across every SDK that implements it, or surface a second mismatch somewhere else in the chain.
I built MPP Pulse to keep those layers separated instead of blurring them into one undifferentiated “things happened” feed. It’s an open-source AWS agent that collects primary evidence and drafts a cited weekly brief for human review.