MPP-I: Machine Payments Protocol for Inference

MPP-I proposes an MPP-native payment profile for metered inference, synchronising payment authorisation with execution, metering, and settlement without placing payment in the per-token critical path.

Abstract

MPP-I (Machine Payments Protocol for Inference) is proposed as an MPP-native payment profile for metered inference. It is designed for autonomous agents, human users, applications, inference wallets, inference providers, settlement methods, facilitators, and blockchain networks that support machine payments. MPP and related Payment HTTP drafts supply the intended 402 challenge, credential, and receipt envelope. MPP-I defines the inference-specific lifecycle inside that envelope.

Inference is not a fixed-price resource access call. A provider can publish machine-readable prices, bounds, and admission requirements, but the final delivered output length is not known when the request is admitted. The serving path must cover prompt tokenisation, prefill, scheduler admission, KV-cache allocation, autoregressive decode, output delivery, and final settlement. MPP-I proposes run-scoped authorisation, cumulative credit grants, signed meter frames, low-credit and drain states, delivered-unit billing, settlement references, and final inference receipts. Its core design goal is to synchronise delivered-output production with payment authorisation, so agents, apps, users, wallets, and providers can use machine payments for metered inference without placing payment in the per-token critical path, while keeping authorisation ahead of the next disclosed admitted interval.

Keywords: machine payments, metered inference payments, HTTP 402, MPP, x402, inference wallets, metered inference, streaming payments.

Executive Summary

MPP-I is a proposed MPP-compatible, inference-native payment profile for metered inference.

MPP and related Payment HTTP efforts are defining a way for agents and apps to pay for API requests, tool calls, and content through an HTTP payment flow. That matters because agents that rely on external resources need a way to buy digital services without human checkout, account setup, invoices, or provider-specific commercial agreements for every call.

Inference is a central resource for that machine-payment flow. An agent may handle memory, tools, routing, policy, and workflow itself, but inference is what lets it reason, plan, generate, verify, and act. Agents that depend on external inference providers need a way to authorise bounded, metered inference when they need stronger reasoning, larger context, specialised capability, or higher reliability than they can run locally. Human users, apps, tools, and inference wallets can use the same payment flow to access inference providers through machine payments.

The problem is that inference does not behave like a fixed-price resource request. The final metered amount due is not known when prefill or scheduler admission begins. The provider must admit prefill, allocate scheduler and KV cache state, and run decode while output tokens are being produced. Once this begins, the provider is already spending scarce serving resources. Holding back the response does not remove that cost. Checking payment only after generation creates provider credit risk. Asking the buyer to authorise the worst case up front creates buyer over-authorisation.

Standard MPP sessions and x402 payment flows provide useful payment, voucher, cap, and settlement primitives, but they do not by themselves define the inference execution lifecycle. For inference, authorisation must remain ahead of admitted execution and be visible to the provider execution gate before the next metering boundary is admitted.

MPP-I defines that lifecycle. It keeps MPP compatibility for the outer 402 challenge, credential, payment, and receipt flow, then adds semantics specific to inference: inference quotes, client policy, authorisation scoped to the run, cumulative vouchers or credit grants, signed meter frames, low-credit states, drain-entry behaviour, hard-stop boundary rules, settlement references, and final inference receipts.

The core execution gate has two related checks:

Here $A_t$ is the latest accepted cumulative authorisation, $A_t^valid$ is the portion of that authorisation that is valid for the relevant gate decision under the grant-validity and settlement-method rules, and $A_t^gate$ is the portion currently usable by the execution gate after policy and run-claimability checks. $P_t$ is boundary-posted cumulative amount due, $B_active,t$ is the maximum cost bound of active admitted intervals not yet posted to due, $C_i^max$ is the admitted bound for interval $i$, and $a_t,i^finish=A_t^gate-P_t-(B_active,t-C_i^max)$. $I_t^+j$ is the active set that would exist after admitting candidate interval $j$, and $a_t,i^finish,+j$ is interval $i$'s hypothetical finish amount under that post-admission active set. Candidate interval $j$ may be admitted only when its own admission headroom $H_j,t^admit(q)$, its drain-entry threshold $D_j,t$, acknowledgement lag, and post-admission finishability all hold. The finish check only allows an already admitted bounded interval to reach its disclosed metering boundary while its own finish headroom remains covered. The acknowledgement-lag check keeps delivered but unacknowledged output within the profile's disclosed range, buffer, or exposure limit; it does not make unacknowledged output billable under the base profile.

The inference plane carries the private request and delivered output. The payment/control plane carries authorisation, vouchers, meter frames, low-credit events, drain events, settlement state, and receipts. These are logical planes, so they may be separate channels or multiplexed over a suitable transport.

If vouchers keep up, inference continues. If vouchers stop, the provider admits no new billable interval, uses only the already authorised headroom for the interval already admitted, stops at the disclosed boundary, settles the metered amount due, and emits a final receipt. Only output that satisfies the selected delivery and acknowledgement boundary is billable as output; under the base profile, delivered but unacknowledged output is reported separately or remains provider risk. Other units, such as prefill, cached input, tool calls, reasoning tokens, multimodal units, KV hold time, or accelerator time, are billable only if they are explicitly priced, metered, and receipted.

MPP-I is therefore a specialised protocol within the MPP family. MPP makes machine payments possible for web resources. MPP-I makes machine payments work for metered inference.

Technical contribution. MPP-I specifies how an inference provider can bind request admission, prefill, decode continuation, cumulative metering, low-credit state, drain and stop behaviour, settlement, and final receipts to MPP-compatible payment authorisation.

Introduction

Machine payment protocols are turning HTTP payment into a usable web primitive: a machine client can request a resource, receive a payment challenge, satisfy it, and get a receipt. That pattern works well for fixed price API calls, paywalled content, file downloads, and other resources whose price is known before delivery.

Metered inference has a different shape. A provider is doing more than releasing a known object after payment. It is admitting a stateful online inference-serving request whose final metered amount due is only partly known when prefill or scheduler admission begins. The prompt must be tokenised and priced. The prefill phase runs before the first visible output token. The request may hold scheduler capacity and key-value cache state. The output length is unknown until generation stops. If payment authorisation stops during a run, the provider can only continue through already authorised headroom before stopping at a disclosed enforcement boundary.

This is the gap MPP-I targets. MPP and related Payment HTTP drafts are defining a common way for machine clients to request payment, satisfy a payment challenge, and receive receipts [mpp]. MPP-I keeps the MPP outer flow and adds the payment lifecycle needed once the paid resource is an inference run:

\raggedrightMPP-I gives metered inference an MPP-native payment profile: inference delivery and payment control are separate logical planes, carried on separate channels or multiplexed with independent control flow, while cumulative authorisation remains ahead of admitted inference execution.

The core rule is a two-gate admission model. In the formulas below, $a_t=A_t^gate-P_t-B_active,t$, where $A_t^gate$ is the latest accepted cumulative authorisation after grant-validity, policy, and run-claimability clamping, $P_t$ is boundary-posted cumulative amount due, and $B_active,t$ is the active admitted bound. For an already admitted interval $i$, $a_t,i^finish=A_t^gate-P_t-(B_active,t-C_i^max)$. For candidate interval $j$, post-admission finishability means:

where $I_t^+j$ is the active set after hypothetically adding $j$, and $a_t,i^finish,+j$ is interval $i$'s hypothetical finish amount under that set.

New billable intervals may be admitted only while the available amount for new work covers the candidate interval's admission headroom $H_j,t^admit(q)$, the candidate drain-entry threshold $D_j,t$, the acknowledgement-lag guard, and the finishability of all intervals that would be active after admission. An already admitted bounded interval $i$ may finish only while its interval-specific finish amount remains at or above the required finish headroom $H_i,t^finish(q)$. When $H_i,t^finish(q) ≤ a_t,i^finish$ but the next candidate admission guard fails, the run is draining: admitted intervals may reach their disclosed boundaries, but the provider must not admit another billable interval until credit is restored. The formal section defines these values from boundary-posted amount due and active admitted bounds. In the base paper profile, delivered but unacknowledged output is provider risk and does not advance cumulative_amount_due. The buyer does not need to authorise a large worst case payment up front. The provider does not need to continue inference beyond claimable payment state or the acknowledgement boundary. The payment system does not need to sit in the critical path for every token.

Illustrative example. An agent asks a provider for streamed inference. The provider replies with an MPP-I quote containing the inference target, tokenizer version, serialisation profile, prefill/input price, delivered-output price, accepted billable units, required initial credit, low and drain-entry watermarks, and metering-boundary policy. The wallet authorises only that run. Meter frames report cumulative delivered usage; grant refreshes are accepted before the next per-run admitted interval. If grants stop, the provider drains through already authorised headroom and stops at the disclosed boundary.

Assume an illustrative tariff of $200 per million billable units, with the same unit price used for input/prefill tokens and delivered output tokens. Each billable unit costs $0.0002. A request with 60,000 input tokens and an initial 10,000 delivered-output-token headroom therefore needs $14 of initial authorisation. If the delivered output reaches 42,000 tokens, the cumulative metered amount due is $20.40 before any separately quoted units such as cached input, tool calls, reasoning tokens, multimodal units, KV-cache hold intervals, or scheduler-admitted accelerator intervals. The final receipt reports actual metered usage, settlement_cap, settlement_target_amount, run_claimable_limit, settled_amount, unused authorisation, released run claimable amount or reservation, and refund amount if applicable. The numbers are illustrative, not normative.

This paper contributes product and protocol framing, not a final standard or registered protocol number. It argues that MPP-I should be specified as an MPP payment profile for inference, using inference as the proposed payment intent name. Until inference is registered or otherwise accepted by the relevant MPP or Payment HTTP process, experimental deployments should identify it as a private or provisional MPP-I profile identifier, or carry it under a registered intent through a profile-specific adapter, and bind that profile identifier to the challenge, quote, policy, grants, meter frames, and final receipt. In this paper, intent means the payment purpose advertised through the MPP payment challenge. Profile means the MPP-I lifecycle rules, object fields, transport expectations, and settlement semantics that make that intent workable for metered inference.

Audience and Scope

This paper is written for inference providers, agent builders, app teams, inference wallet teams, payment facilitators, settlement-method builders, blockchain networks, protocol engineers, and decentralised inference networks. It assumes the reader understands HTTP APIs, tokenisation, prefill/decode accounting, and usage-based inference pricing, but it does not assume deep payment channel or inference engineering expertise.

The scope is focused. MPP-I is a payment profile for metered inference. It can produce signed records of inference target, tokenizer ID, usage, timing, content-private commitments, metered amount due, and settlement reference. It does not prove inference quality. It does not solve legal compliance, consumer disputes, chargebacks, tax, sanctions screening, or all settlement finality questions. Those systems can be implemented around MPP-I, but the profile should not claim to provide them.

This paper is not legal, regulatory, tax, accounting, investment, or financial advice. It does not recommend any payment method, asset, facilitator, wallet, jurisdiction, or compliance posture. Terms such as wallet, facilitator, settlement, reservation, and claimability are used as protocol design roles and state descriptions, not as determinations of legal status. Implementers remain responsible for evaluating licensing, money transmission, anti-money-laundering obligations, sanctions, consumer protection, tax, data protection, and settlement finality obligations for their jurisdictions, counterparties, and selected payment methods.

Background: Machine Payments and MPP Compatibility

Current machine payment work is converging around HTTP 402, signed payment authorisations, stablecoin settlement, facilitators, payment sessions, and off-chain vouchers. These draft and implementation primitives are useful, and MPP-I should reuse them where the selected profile supports the same semantics. The problem is that they mostly answer payment admission and settlement questions. MPP-I addresses the inference execution lifecycle questions involved in admitting, continuing, draining, stopping, settling, and receipting an inference run.

As of June 28, 2026, Payment HTTP authentication and related MPP materials are active draft work. This paper therefore uses MPP compatibility as an interoperability target, not as a claim that MPP-I is already standardised. Mutable documentation references were checked on June 28, 2026; a final standards-track release should prefer dated drafts, release versions, permalinks, or archived snapshots where available.

Payment HTTP Authentication

The relevant primitive is the emerging Payment HTTP authentication scheme. A server can return 402 Payment Required with a WWW-Authenticate: Payment challenge; the client fulfils the payment requirement and retries with an Authorization: Payment credential; the server verifies or settles the payment and returns the protected resource with an optional Payment-Receipt [paymentauth].

The key design choice is extensibility. The Payment scheme is payment method agnostic. Concrete payment methods define their own request schemas, payload schemas, verification rules, and settlement procedures. Payment intents describe the type of payment being requested, and intent specifications define semantic meaning, request fields, payload requirements, verification, and settlement semantics [paymentauth].

Payment HTTP authentication is a good envelope for MPP-I. MPP-I can be defined around a proposed inference payment intent rather than as a new HTTP payment framework. Before any formal registration, a deployed profile should treat inference as a private or provisional profile identifier, or carry it through a registered intent with a profile-specific adapter, so early experiments do not imply standards-track wire compatibility. The missing layer is inference execution semantics: the Payment scheme does not say how much inference may be executed after a partial authorisation, when low-credit warnings should fire, when a provider must drain and stop, or what an inference receipt must contain.

Large inference quotes and receipts should not be forced into oversized payment headers. The MPP-I profile should allow compact header payloads containing IDs, hashes, short fields for the selected method, and references to signed quote or receipt bodies. Any referenced object must be bound by digest to the challenge or credential so it cannot be swapped after approval.

The MPP-I FinalReceipt is not automatically the same object as the HTTP Payment-Receipt header. A profile may carry or reference a FinalReceipt through Payment-Receipt only where the underlying HTTP response semantics allow it. Otherwise, FinalReceipt should be treated as a signed control plane object, response body, trailer, or referenced receipt object that is bound back to the payment challenge, run, policy, meter frames, and settlement reference.

Charge-Style Payments and Stablecoins

The charge intent for Payment HTTP authentication defines a one-time exchange of payment for resource access [chargeintent]. The payer provides proof of payment, or a signed authorisation to collect payment, and the server grants access. Method-specific drafts define how this works over particular settlement methods, such as EVM ERC-20 transfers or Solana SPL tokens [evmcharge, solanacharge]. Stablecoin-denominated charge methods can be useful in the same family because they standardise fixed machine payments over supported settlement paths.

Charge-style payments are useful for fixed API calls, quote fees, cached results, deposits, initial prefill grants, and final settlement. They are not enough for open-ended streaming inference. A fixed charge assumes the amount is known before access is granted. A generation may end after 20 output tokens or 2,000. The fixed charge primitive can carry money, but it does not decide how inference proceeds while cost is still accumulating.

x402

x402 uses HTTP 402 to let clients pay for web resources programmatically. Its exact scheme is fixed price: the seller advertises one amount, the buyer signs that amount, and a facilitator settles the payment for the request [x402exact]. This works when the final charge is known before the response is generated.

x402's upto scheme is a useful adjacent payment primitive. The buyer authorises a maximum for one request, and the seller settles actual usage up to that maximum. The x402 documentation explicitly names LLM token generation, bandwidth, compute time, and dynamic data queries as use cases [x402upto]. This can settle unknown actual usage under a request-level cap, but it is still not an inference execution-control protocol. During streamed generation, the primary response path is occupied by inference output. If the provider only computes or settles actual usage after the response completes, it has not observed fresh claimable authorisation while prefill and decode were consuming serving capacity. A high cap protects the provider and over-authorises the buyer. A low cap protects the buyer and risks truncation at the wrong boundary.

x402's batch-settlement scheme addresses another practical issue: high-throughput settlement. It uses escrow, off-chain cumulative vouchers, fast server verification, and later batched on-chain redemption [x402batch]. That mechanism is useful for repeated inference calls and small meter increments. It is still a settlement mechanism unless its vouchers are run-bound, forward-looking, sequenced, and visible to the inference execution gate before the next boundary is admitted. MPP-I must define the run lifecycle, buffer policy, meter cadence, low-credit and drain behaviour, stop behaviour, and receipt fields. x402-compatible caps, facilitators, or batch-settlement paths are compatible with MPP-I only when paired with an inference payment/control path that carries run-bound cumulative grants, meter acknowledgements, low-credit signals, and stop or drain state before the next metering boundary is admitted.

The compatibility point needs precision. Payment HTTP authentication uses WWW-Authenticate: Payment, Authorization: Payment, and Payment-Receipt headers. x402 uses HTTP 402 concepts and payment flows backed by facilitators, but its wire objects and headers are not automatically the same as Payment HTTP authentication. MPP-I can use settlement paths or adapters compatible with x402 where they preserve run binding, cumulative authorisation, and receipt semantics, but that is compatibility by profile and adapter, not automatic wire equivalence.

MPP Sessions

MPP session patterns are the closest existing primitive. A session intent establishes reusable funding or voucher state for metered usage, often using escrow and off-chain vouchers so the client can authorise increasing cumulative amounts without settling a separate payment for every streamed chunk. Current MPP session materials explicitly discuss high-frequency, pay-as-you-go usage: a client funds reusable payment state, the server delivers metered work, the client authorises cumulative amounts, and the server settles periodically or at stream completion [mppsession].

MPP sessions are a useful adoption bridge for MPP-I, but the distinction matters. A standard payment session says how value is incrementally authorised. It becomes an MPP-I deployment only when session updates are coupled to the provider's prefill and decode gates during the run. MPP-I adds that coupling: prefill starts only after initial run-bound credit; decode continues only while the latest accepted voucher or credit grant covers the next disclosed metering boundary; low-credit, drain, stop, and receipt messages are sequenced against delivered output and metered usage. Semantics for inference should not be hidden inside provider-specific policy.

Related Work and Prior-Art Positioning

Adjacent agent-payment work is complementary rather than equivalent. Google's Agent Payments Protocol (AP2) focuses on agent-led payment authority, accountability, and commerce across payment methods, while the A2A x402 extension brings on-chain x402 payments into agent-to-agent service flows [ap2, a2ax402]. These efforts help explain why agents need interoperable payment authority, but they do not define an inference provider's prefill, decode, low-credit, drain, stop, and final receipt lifecycle.

There is also direct adjacent work on usage-based inference settlement. Polygon's x402 per-inference guide uses the upto scheme so a buyer authorises a per-call maximum and the server settles actual token, compute, or output usage after measuring it [polygonInferenceBilling]. Fortytwo's x402Escrow extends x402 with escrow for usage-based, pay-per-token AI services where cost is unknown at request time [fortytwoEscrow]. These are important prior-art signals: they show the market is already moving toward accountless, usage-based inference payment. As published, they primarily address capped settlement, middleware, or escrow mechanics. MPP-I addresses the inference execution boundary itself: it specifies run-scoped authorisation, scheduler-visible payment state, admitted intervals, cumulative grants, meter frames, delivery acknowledgements, low-credit and drain semantics, stop boundaries, and final inference receipts.

Security work on x402 also supports making these bindings explicit. A 2026 analysis of x402-enabled payment systems identifies state-synchronisation and logic-flaw classes such as cross-resource substitution, duplicate-settlement race conditions, allowance overdraft, and denial of settlement in agentic payment flows [x402LogicFlaws]. MPP-I treats those risks as protocol-design requirements: run identifiers, request commitments, claim references, cumulative monotonic grants, meter-frame sequencing, delivery acknowledgements, and idempotent final receipts are not implementation decoration; they are the control surface that keeps payment state tied to the inference work being admitted.

Current State Payment Flows

Most machine payment protocols today are optimised for resource access and payment admission, not execution control inside an online inference-serving path. They can challenge a client, verify a payment credential, settle a fixed or capped amount, and return a resource. That is enough when the price is known before delivery. It is incomplete when the resource is an inference run whose cost evolves during prefill, decode, tool use, and possible state hold.

Fixed Price HTTP 402 Pattern

Figure~[fig:today-fixed-402] shows the common fixed price pattern. The key property is that the seller can state the amount before granting access. That maps cleanly to content, file downloads, cached API results, and bounded fixed price calls. It does not say what should happen while decode is still producing output and the final metered amount due is unknown.

Single-Channel Streaming Payment Failure

In a conventional streamed inference API, the primary response path carries output events such as SSE chunks, WebSocket messages, or gRPC stream messages. If payment checks rely on that same occupied response path, the provider has two poor choices. It can interrupt output while waiting for fresh payment state, which damages time to first token or inter-token latency. Or it can continue prefill and decode, then check payment after generation, which does not bound maximum unpaid admitted work because the serving cost has already been incurred. The failure is not value transfer in isolation; it is the absence of a run-scoped payment/control path that keeps claimable authorisation ahead of prefill and decode and is visible to the execution gate before the next metering boundary.

Request-level caps reduce the problem but do not solve inference metering. A large cap over-authorises the buyer. A small cap truncates the run or forces a stop at a boundary that may not match the serving engine's safe metering point. A generic session or voucher stream helps only if its updates are visible to the execution gate before the next prefill/decode interval is admitted.

The missing piece is not another provider-specific billing system. It is a shared inference payment state machine that agents, apps, inference wallets, and inference providers can all evaluate. Without that state machine, every provider has to define its own meanings for low_credit, draining, stopped, grant refresh timing, settlement, and final receipts.

Why Inference Is Different

Inference is economically closer to a metered, stateful compute session than to a fixed price content retrieval. The cumulative metered amount due can be bounded by policy, but exact usage is not known at request admission.

Prefill, Decode, and Latency

Modern text-generation serving usually separates inference into two phases. Prefill processes the input prompt and prepares the state needed for generation. Decode generates output tokens autoregressively, one step at a time. NVIDIA's benchmarking documentation defines time to first token (TTFT) as the time from request submission to the first output token and notes that TTFT generally includes queuing, prefill, and network latency [nvidiaMetrics]. It defines inter-token latency as the latency between consecutive output tokens, a measure tied to the decode portion of a request [nvidiaMetrics].

This phase structure matters for payment. The provider incurs meaningful cost before the buyer sees the first useful output. The provider cannot know the final output length at the moment it accepts the request. Even when a buyer supplies max_tokens, that value is an upper bound, not the final metered amount due.

Production systems expose this uncertainty in their own quota systems. Amazon Bedrock illustrates the same reservation versus actual usage distinction in quota form: it reserves quota up front using input-related tokens and the requested output bound, adjusts quota during or after processing according to actual output and provider-specific burndown behaviour, and bills for actual token usage [bedrockQuota]. That pattern is not a payment protocol, but it illustrates the same structural problem: admission wants a reservation, while settlement wants actual usage.

For MPP-I, admission should make prefill cost explicit before serving-engine execution. A provider can tokenise and price the request before issuing an executable quote, or it can issue a conservative prefill bound and correct the quote before prefill begins. In either case, the initial credit grant should cover exact or conservatively bounded prefill cost plus the first execution headroom:

Here $ceil( x)_unit$ means rounding up to the smallest unit of the selected payment or settlement method after applying the quoted price schedule.

Here $C_prefill,0^bound$ is the exact or conservative money-denominated prefill cost disclosed in the quote, and $H_decode,0^admit(q)$ is the admission headroom for the first decode interval under the selected profile. This one-step initial-credit formula applies only when the quoted prefill cost is exact or conservatively bounded through the next enforceable prefill boundary. Chunked or long-running prefill profiles must define $C_next,t^max$, $H_j,t^admit(q)$, metering cadence, and stop behaviour for prefill segments before decode admission. A profile may use a two-gate procedure instead: admit prefill under the prefill bound, meter it, then admit decode only after the payer has authorised the first decode headroom.

An executable quote needs to bind more than a model name and a tokenizer name. It should bind the serialisation and tokenisation surface that determines input length and prefill cost: tokenizer ID and version, chat template or canonical serialisation profile, special-token policy, tool or function schema hash, multimodal preprocessing profile where used, context-window and truncation policy, cache-hit class, and the exact or conservative input-token count. The payment/control plane should bind these fields by ID, digest, or hiding commitment. It should not receive the raw prompt or raw serialised request.

KV Cache and Scheduler State

KV cache is not accounting trivia. It is a scarce serving resource. The PagedAttention paper argues that high-throughput inference serving is constrained by key-value cache memory that is large and dynamically changes as requests grow and shrink [pagedAttention]. vLLM's public write-up explains the same issue in operational terms: KV cache can be large, depends on sequence length, and inefficient management wastes memory through fragmentation and over-reservation [vllmBlog].

This is why the word ``pause'' should be used carefully. A provider can stop sending bytes to a client, but the request is either retained in scheduler state with KV-cache state resident, or it is evicted and must be recomputed or restarted. The cost is implementation-dependent and load-dependent, but it is not zero in systems optimised for low latency and high utilisation.

If a profile makes KV hold time billable, it should define the meter rather than naming the resource loosely. Useful fields include run or cache scope, token span, residency tier, start and end time, maximum hold, eviction policy, recompute behaviour, and whether the meter is provider-asserted, audited, or attested. Active-request KV, reusable prefix cache, offloaded KV, and evicted state have different costs and different verification properties.

In disaggregated serving, prefill, KV transfer, and decode may run on different workers or queues. MPP-I does not need a separate protocol for that shape. The profile should treat each exposed phase as a distinct admitted interval when it is billable: prefill admission, KV transfer or residency, and decode continuation each need an explicit quote, meter, receipt field, and headroom boundary.

Payment headroom is not the only admission policy. A production profile should also let providers disclose queue timeout, priority class, per-wallet or per-tenant concurrency, active KV-token cap, overload rejection behaviour, reservation expiry, and reservation release rules. These fields should describe the provider's admission policy; MPP-I should not try to impose a single universal scheduler fairness algorithm.

Streaming Tightens the Tradeoff

Streaming is a product feature, not just a transport detail. A metered inference protocol has to preserve low TTFT, stable output-token cadence, and bounded inter-token latency under typical conditions. If every token waits for an on-chain transfer or a human wallet approval, the serving path fails. If the provider streams a long answer before payment state is claimable, the provider extends credit beyond the disclosed exposure bound. If the buyer signs a large maximum for every call, the buyer over-authorises or locks capital.

The Inference Payment Trilemma

The central trade-off is a trilemma. A naive protocol cannot maximise all three goals:

1. Low TTFT and uninterrupted streaming.
2. Exact final payment for actual usage.
3. Hard-bounded or risk-budgeted provider exposure and no buyer over-authorisation.

If the provider streams first and settles later, the buyer gets low latency and actual-usage settlement, but the provider accepts maximum unpaid admitted work that is not constrained by payment state. If the provider requires a high maximum authorisation before execution, unpaid work is constrained and streaming can proceed, but the buyer over-authorises against a worst case. If the provider requires payment at very fine token boundaries on the same occupied output path, the buyer and provider can keep unpaid work small in theory, but payment-control latency enters the decode path and can degrade streaming.

The trilemma is an engineering trade-off, not an impossibility theorem. Fixed prices work for small bounded calls. Subscriptions and prepaid balances work inside durable commercial relationships. High upto caps work when buyers tolerate capital lock-up. The claim here is specific: open-ended streamed inference needs explicit execution semantics to keep bilateral risk either hard-bounded under deterministic profiles or risk-budgeted under disclosed quantile profiles without putting payment in the per-token critical path.

Design Goals and Out of Scope

Goals

1. Bound unpaid admitted work. A provider should know the unpaid compute it can admit for a run under the selected risk-budget or hard-bound profile.
2. Bound buyer authorisation. A buyer should authorise spend according to policy rather than sign a large worst case amount for every request.
3. Protect streaming quality. Top-up cadence should be designed and measured so it does not stall decode or materially increase TTFT under expected operating conditions.
4. Stay compatible with MPP. MPP-I should use MPP's challenge, credential, and receipt model while defining lifecycle semantics for inference through a proposed inference intent or profile.
5. Keep settlement method flexibility. MPP-I should not mandate a settlement rail, asset, processor, or single facilitator. The selected payment method compatible with MPP should carry or settle the payment while MPP-I defines inference semantics.
6. Make receipts auditable without exposing inference content. Final receipts should reconcile request commitments, delivered unit commitments, usage, timing, metered amount due, and settlement references without putting raw prompt, raw output, or raw transcript on the payment plane.
7. Define termination explicitly. Low credit should lead to defined states such as low_credit, draining, stopped, and settled; not an ambiguous pause.

Out of Scope

1. No semantic output quality guarantee. Base MPP-I can receipt what was run and metered; it cannot prove the answer was useful or correct.
2. No mandatory settlement method. The protocol should not require a settlement rail, asset, processor, or single facilitator.
3. No universal pricing policy. Providers set prices. MPP-I standardises how prices and billable units are represented.
4. No full dispute court. The base layer should support evidence for disputes, not adjudicate subjective output quality.
5. No requirement for token-synchronous payment. Payment authorisation should be ahead of execution, metered cumulatively, and refreshed at coarse enough intervals to preserve serving performance.

Proposed Solution Overview

MPP-I turns payment state into an explicit inference payment synchronisation contract. The protocol does not require a specific settlement rail, asset, processor, or facilitator. Instead, it defines the objects and state transitions that connect an MPP payment authorisation to an inference run.

Target Architecture

Figure~[fig:mppi-architecture] separates the inference plane from the payment/control plane. The inference plane carries the request payload and streamed inference output. The payment/control plane carries quote and policy state, reservations scoped to the run, cumulative credit grants, signed meter frames, low-credit and drain events, cancellation, settlement references, and receipts. The payment/control plane must never carry raw prompt, raw output, or raw transcript. The provider gateway verifies admission, but the decisive enforcement point is the scheduler or worker admission gate: no new billable interval should enter the serving path unless the current payment state covers the next disclosed interval.

End-to-End Run Lifecycle

Figure~[fig:mppi-facilitated-swimlane] shows the facilitated run as a sequence across the agent, wallet, facilitator, provider gateway, scheduler, and settlement path. Figure~[fig:mppi-run-lifecycle] summarises the same lifecycle as operational steps. Direct mode removes the facilitator but keeps the same quote, policy, grant, meter, payment state, and receipt semantics. Payment authorisation is necessary for an MPP-I run, but it is not the same as scheduler admission. A queued run should carry the payment-state version and grant sequence that authorised it, and the provider should revalidate that state before the run becomes scheduler-admitted work.

A wallet receives raw output only when the quote and policy explicitly designate it as the client-side receiver or transport adapter. A wallet that only signs spend policy or credit grants remains on the payment/control plane and should not be treated as the raw-output recipient or factual delivery observer by default. A wallet or facilitator may sign DeliveryAck only when the quote and policy designate it as acknowledgement authority for a concrete transport boundary. If it observes raw output to make that acknowledgement, it is acting as an inference-plane receiver or transport adapter for that purpose, not as a control-plane-only wallet or facilitator.

What Changes Relative to Today

Table~[tab:mppi-changes-relative] summarises the practical shift from current payment flows to the proposed MPP-I flow.

Protocol Model

Actors

Two Logical Planes

MPP-I should define logical behaviour rather than requiring a single transport in the paper-level protocol. The front matter defines this paper's non-normative language convention; formal conformance requirements belong in the eventual profile specification once it fixes exact schemas, transport mapping, and settlement method behaviour.

Inference plane. The provider receives the private inference request and streams delivered output units such as text tokens, tool call outputs, or multimodal outputs. This plane may carry raw prompt and raw output between client and provider, subject to the provider's privacy and security commitments.

Payment/control plane. The client, wallet, or facilitator opens a run, reserves or locks claimable funds, submits initial credit, sends top-up credit grants, receives signed meter frames, receives low-credit and drain events, cancels, and receives settlement references and final receipts. This plane carries only policy, accounting, and content-private commitments. It must not carry raw prompt, raw output, or raw transcript.

The planes may run over WebSocket, HTTP/2 streams, gRPC, SSE plus POST, HTTP/3, WebTransport, or another transport. What matters is that control messages are ordered, protected against replay, bound to the run, and visible to the provider's scheduler or worker admission gate before compute continues beyond the covered metering boundary.

Independent streams still need application-level sequencing. Delivered output should have a monotonically increasing delivered sequence. Meter frames should state the delivered sequence range and any separate billable event range they cover. Credit grants should acknowledge the latest accepted meter frame sequence. When output billing uses acknowledged_delivered_output, credit grants after the initial grant should also carry the latest acknowledged delivered sequence or range used by the payer, wallet, facilitator, or transport adapter. Low credit, draining, stop, cancellation, and final receipt messages should also be sequenced and bound to the run. On reconnect, both sides resume from the highest mutually accepted meter frame and the latest accepted cumulative grant; duplicate messages are idempotent, and older grants cannot reduce the latest accepted authorisation.

Each transport profile must define what delivered means. The default billable output boundary should be acknowledged_delivered_output: output included in a signed delivered sequence and acknowledged at the application layer by the client, or by a wallet, facilitator, or transport adapter that the quote and policy explicitly authorise to acknowledge that delivery boundary. A wallet or facilitator that does not observe the output or the relevant transport boundary should not be treated as acknowledging delivered content except as an authorised proxy for a client-side or transport-adapter acknowledgement. For the base text-output profile, output may enter cumulative_amount_due only when it is in a signed delivered sequence at or below the latest accepted DeliveryAck for the run. Delivered but unacknowledged output should be reported separately from billable output or remain provider risk. A profile may use a weaker boundary, such as server flush or socket write, only if that choice is disclosed in the quote and policy; weaker delivery semantics shift dispute risk and should not be hidden behind the word delivered.

Transport profiles should also define the operational limits that keep delivered-output billing unambiguous: flow-control windows, maximum buffered bytes or output units, acknowledgement cadence, maximum unacknowledged delivered range or acknowledgement-lag range, slow-consumer policy, half-close behaviour, reconnect state, and whether acknowledgement is made by the application, wallet, facilitator, or transport adapter. Per-output acknowledgements may be too expensive for low inter-token latency, so profiles should choose an acknowledgement cadence that keeps dispute exposure constrained without putting acknowledgement on the critical path of every decode iteration. If a client exceeds the maximum buffered output or maximum acknowledgement-lag range, the provider should apply the disclosed slow-consumer policy: emit ack_lag_low or ack_lag_exceeded, pause emission, or stop at the next enforceable delivery boundary. Output beyond the acknowledged delivered range is provider risk unless the quote and policy disclosed a weaker delivery boundary.

When acknowledged_delivered_output is the billing boundary, acknowledgement should be a first-class signed DeliveryAck, not only an implied side effect of a grant or transport read. A DeliveryAck binds the authorised acknowledgement role, delivered range, delivered-unit commitment, meter-frame reference where one exists, and signer to the run without exposing raw output on the payment/control plane. Meter frames that advance output amount due should reference the accepted DeliveryAck sequence or hash. Meter frames may also report a delivered but unbilled range so the client and provider can reconcile slow consumers, reconnects, and final stops without treating unacknowledged output as billable output. Profiles should also define signed and sequenced Resume, Cancel, Stop, and terminal messages. Those messages need a state vector covering the latest delivered sequence, latest accepted DeliveryAck sequence and hash where used, latest accepted meter frame sequence and hash, latest accepted grant sequence and hash, control message sequence, and terminal state if one exists. Race precedence should be explicit: terminal settlement closes the run, stale top-ups cannot reopen it, stale cancels cannot erase already admitted metered work, and duplicate terminal messages settle idempotently against the same run and payment path.

High Performance Transport Example

MPP-I is aware of transport profiles, but it is not prescriptive about transport. A low-latency serving profile can expose an HTTP endpoint compatible with MPP for payment admission and then run the inference session over independent HTTP/2 or gRPC streams:

1. The agent requests inference. The provider replies with an MPP 402 challenge carrying an MPP-I quote.
2. The client or inference wallet approves a policy and submits the initial authorisation for the run.
3. The provider starts the run and opens one stream for delivered inference output and another independent stream for payment/control messages.
4. The client, wallet, facilitator, or transport adapter authorised by the policy signs DeliveryAck messages for delivered ranges under the selected acknowledgement cadence.
5. The provider emits signed cumulative meter frames at disclosed boundaries. In the acknowledged-billable profile, output amount due advances only through the latest accepted DeliveryAck. The wallet or facilitator responds with cumulative credit grants before the drain-entry watermark is reached.
6. If grants stop arriving, the provider drains only through already authorised headroom, emits draining, stops at the disclosed boundary, settles the final amount up to the latest valid cumulative grant, client policy, and run claimable limit, and emits a final receipt.

This shape avoids token-synchronous payments. Grant verification must fit within the profile's p99 grant-verification budget, while the execution gate only needs to know whether available amount covers the next disclosed billable interval. The same transport-independent protocol lifecycle can be carried over SSE plus a side-channel POST endpoint, WebSocket, or HTTP/3/QUIC/WebTransport when those transports preserve ordering, replay protection, run binding, flow control, acknowledgement semantics, and the privacy boundary between inference content and payment metadata.

Payment Synchronisation State

Payment synchronisation state is run-level accounting state local to the provider unless a transport profile explicitly exposes part of it. Every quantity used in the execution gate should be denominated in the smallest unit of the selected payment or settlement method. Tokens, time, tool units, multimodal units, reasoning tokens, cached input, KV hold intervals, and scheduler-admitted accelerator intervals may be billable unit types only when explicitly quoted, metered, and receipted. They must be converted through the quoted price schedule and rounded up before comparison.

Provider-observed units and units that are not output require a stronger verification regime than visible output tokens. The base paper requires them to be quoted, admitted, metered, and receipted, but it does not make them independently verifiable. A formal profile should declare the provider assumption, or add an attestation profile, audit process, or dispute-opening mechanism, before claiming independent verifiability for reasoning tokens, internal compute, KV hold time, or scheduler-admitted accelerator time.

For the base profile, amount due is boundary-posted. Let $A_t$ denote latest accepted cumulative authorisation, $A_t^valid$ the portion of that authorisation that is valid for the relevant decision point under the grant-validity and settlement-method rules, $P_t$ boundary-posted cumulative amount due, and $I_t$ the set of active admitted intervals that have not yet reached their metering boundary. The execution gate must use only currently claimable, policy-valid run funds:

If a profile already defines $A_t$ as a provider-verified, valid, policy-clamped, run-claimable amount, then $A_t^gate=A_t$. Otherwise, $A_t^gate$ is the amount used by admission and finish gates. A signed grant that is expired for the relevant decision point, not accepted under the causal grant rule, or not backed by current run claimability cannot increase $A_t^gate$. Each interval $i ∈ I_t$ has an admitted maximum cost $C_i^max$. The provider computes:

Here, posted_cumulative_amount_due is the provider-local name for the accrued billable amount for the run that has reached disclosed metering boundaries. The canonical wire-facing field name in signed meter frames and receipt bindings is cumulative_amount_due; it means the same boundary-posted amount, not provisional generated usage. A profile must not give posted_cumulative_amount_due and cumulative_amount_due divergent semantics. For output under the base text-output profile, this amount advances only for output covered by the selected delivery and acknowledgement boundary. Non-output units advance it only when they are separately quoted, admitted, metered, and represented as billable events.

Candidate admission uses a hypothetical post-admission active set. For candidate interval $j$, define:

The ordinary $a_t,i^finish$ value is used for intervals that are already admitted. The $+j$ value is used only to test whether all intervals that would be active after admitting candidate $j$ remain finishable.

Grant validity and method claimability must be evaluated at explicit decision points. A profile should define whether valid_until, policy expiry, and settlement-method claimability are checked at candidate admission, interval finish, meter posting, settlement submission, finality, or all of those points. The base paper rule is conservative: a candidate interval may be admitted only if the accepted grant and method claimability are valid for the interval's disclosed boundary or the method profile creates a run-scoped claimability snapshot that remains enforceable through that boundary. If the payment method cannot prove claimability through the boundary, the provider must shorten the interval, request fresh authorisation, or stop before admitting it. The active_admitted_interval record should therefore snapshot the grant sequence, cumulative authorised amount, grant validity or claimability evidence, payment-state version, run-claimable limit used for the gate, and settlement-method reference needed to verify the final receipt.

Each admitted interval must also map back to the executable quote. The interval's $C_j^max$ should be computed from a named quote line item, metering-boundary profile, billable unit type, unit-count or time bound, price schedule, rounding rule, and any evidence profile used for non-output units. The maximum_cost in the interval record is that computed $C_j^max$, expressed in the smallest payment unit. The quote-level $C_next,t^max$ should be either a derived alias for the next candidate interval's computed $C_j^max$, or a disclosed maximum-admitted-interval cap that every candidate $C_j^max$ must not exceed. A verifier should be able to reconstruct this mapping from the quote, policy, meter frame, and final receipt without seeing raw prompt or raw output.

The base transition order is explicit:

1. Apply all accepted grants and already posted meter frames for the run. Compute \(A_t^gate\) from valid accepted authorisation, policy maximum, and current run claimability, then compute \(a_t=A_t^gate-P_t-B_active,t\). This pre-admission value is used for \(may_admit_new_interval_j,t\), drain-latch checks for new work, and the credit-state label that existed before the candidate interval is admitted.
2. For candidate interval \(j\), compute \(C_j^max\), \(H_j,t^admit(q)\), the interval's \(H_j,t^finish(q)\), and the hypothetical post-admission values \(I_t^+j\), \(B_active,t^+j\), and \(a_t,i^finish,+j\). The provider must not admit \(j\) unless the admission gate holds and every interval that would be active after admission remains finishable under its own finish guard.
3. If admitted, append an active_admitted_interval record with the interval ID, unit type, quote line item, metering-boundary profile, admitted boundary, unit-count or time bound, maximum cost, rounding rule, pricing reference, evidence profile, latest payment-state version, latest grant, grant-validity or claimability snapshot, latest accepted meter frame, and latest acknowledgement reference where used. Then compute \(a_t^reserve(j)=A_t^gate-P_t-(B_active,t+C_j^max)\). This post-reservation value may trigger low_credit, draining, or no-new-admission state for future intervals, but it does not retroactively invalidate interval \(j\) if the admission and finish guards held at admission.
4. During execution, posted_cumulative_amount_due does not advance for interval \(j\) unless the profile defines a stricter continuous-posting rule.
5. At the disclosed boundary, emit a MeterFrame, post the actual billable amount to posted_cumulative_amount_due, remove or reduce the interval's active bound, compute \(a_t^posted\), then recompute credit_state, acknowledgement state, and drain latch before any further admission.

This separates work that is already due from work that is admitted but still in flight.

Bare headroom names such as $H_j,t^admit$ and $H_i,t^finish$ are informal aliases only after a quote or deterministic profile fixes $q$. Gate predicates in this paper use the canonical $H_j,t^admit(q)$ and $H_i,t^finish(q)$ forms.

Before admitting any prefill segment, per-run decode window, accepted speculative-token burst, tool unit, multimodal unit, reasoning step, KV hold interval, or scheduler-admitted accelerator interval that has been explicitly quoted as billable, the provider must compute admission headroom for the candidate interval. In the base paper profile, admission headroom is a disclosed risk budget:

An already admitted interval has different finish semantics because its maximum cost bound is already present in $B_active,t$. The finish-headroom term should cover only residual control-latency exposure, tail exposure, and any profile-defined hard-stop margin needed for interval $i$ to reach its disclosed boundary. It should not add $C_i^max$ a second time unless the profile deliberately defines finish headroom that way:

Here $C_residual,i,t^max$ is the profile-defined maximum additional billable cost, excluding the interval bound already reserved in $B_active,t$, that may accrue while interval $i$ reaches its boundary. A simple text-output profile may set $C_residual,i,t^max=0$ when the admitted output window is already fully reserved. $M_exec$ is a floor on total admission or finish headroom in these formulas, not a residual amount that must remain after reserving $C_j^max$. A profile that wants a residual post-reservation buffer should use a different formula and name that residual explicitly. A profile that wants to admit another interval after $i$ posts must run the admission gate again; it should not hide next-interval admission inside the finish guard.

$E_unacked,t$ is a profile-defined money calculation, not a second unit counter. The profile must derive it from the delivered but unacknowledged range, the selected delivery boundary, the quote's price schedule, and the rounding rule. For a simple text-output profile:

where $U_unacked,t$ contains the delivered output units after the latest accepted acknowledgement and before the latest delivered boundary, and $price_Q(u)$ is the quote-bound unit price for $u$. For mixed modalities, tool outputs, accepted speculative tokens, weaker delivery boundaries, or other priced output classes, the profile must state which unit types enter $U_unacked,t$, how each unit is priced, and whether rounding occurs per unit, per class, per frame, or at the aggregate run level. This exposure remains provider risk under the base acknowledged-billable profile; it does not advance $P_t$ until the selected billing boundary is met.

Headroom aliases. $H_t^state$ is a scalar credit-state label, not an execution gate. A formal profile may compute it from active finish guards by using a conservative projection such as:

where $H_floor,t$ is a non-negative profile stop floor, and the maximum over an empty active set is ignored. This follows from $a_t,i^finish=a_t+C_i^max$. A profile may choose another scalar projection, but it must define it. If no scalar projection is defined, credit_stopped must be computed from explicit failed finish guards rather than a bare $H_t$.

Drain latch. New interval admission and admitted-interval completion are intentionally different gates. Crossing $D_t$ latches monetary draining: the provider may finish already admitted bounded intervals only while the interval-specific $may_finish_interval_i,t$ condition holds, and must not admit another output-producing or otherwise billable interval until a valid top-up restores $a_t ≥ D_j,t$ and $a_t ≥ H_j,t^admit(q)$ for the next candidate interval. A profile may instead define $D_j,t$ to subsume admission headroom by requiring $D_j,t≥ H_j,t^admit(q)$, but the comparison must be explicit in the profile.

Acknowledgement limits. A profile may set a range limit, an exposure limit, or both. In these guards, an omitted acknowledgement limit is treated as $+\infty$, or equivalently the profile may define an explicit enabled acknowledgement-constraint set. The quote and policy should identify the unit basis and scope for each enabled acknowledgement limit. These limits constrain slow-consumer and acknowledgement-lag exposure; they do not make unacknowledged output part of posted_cumulative_amount_due under the base acknowledged-billable profile.

Headroom profile. A profile should state whether headroom is a quantile-based risk budget or a deterministic hard bound. In this paper, hard-bounded means the profile enforces deterministic maxima for the admitted interval and control delay. Risk-budgeted or profile-bounded means the profile discloses a measured or simulated quantile, safety factor, tail-overrun handling, and reporting rule.

The term $C_next,t^max$ is the maximum cost, under the quote's price schedule, of the next billable interval before an enforceable metering boundary. That interval may cover prefill admission, a chunked-prefill segment, a per-run decode step or decode window, an accepted speculative-token burst, a bounded tool call unit, a bounded multimodal unit, a bounded reasoning token interval, a bounded KV hold lease interval, or a bounded scheduler-admitted accelerator interval if those units are part of the quote. A global continuous-batching engine batch is not itself a buyer-visible billing unit unless the profile defines per-sequence accounting inside it. The quote should disclose the metering boundary policy, meter cadence, maximum admitted interval, $C_next,t^max$ bound, $q$, $\gamma$, $B_tail,t$, and rounding behaviour. This is the invariant that makes unpaid admitted work auditable against a disclosed profile: after the last valid gate, the provider should be able to spend no more than the disclosed interval plus the selected latency risk budget before reaching the disclosed hard-stop boundary, except for tail overruns handled by the profile.

The term $C_latency,t^(q)$ covers billable units that may accrue while payment/control messages propagate and become visible to the execution gate. $U_active,t$ defines the quoted billable unit types, rates, and enforced maxima that feed that exposure calculation. The defensible profile default is an end-to-end measured or simulated quantity, not a product of independent component quantiles. Let $D_control,t$ be the measured or simulated distribution of billable cost accrued from the control trigger, such as meter emission, low-credit transition, top-up submission, drain decision, or stop decision, until the resulting grant, drain, or stop decision is visible at the scheduler or worker admission gate:

If a profile uses component measurements instead, it must define the composition rule. Acceptable examples include a conservative union-bound allocation across component tails, a joint-distribution estimate that preserves correlation between output rate, verifier latency, scheduler lag, and reconnect delay, or a deterministic hard-bound profile with enforced maxima. A sum of component p99 values should not be described as the p99 of total control delay unless the profile defines why that composition is valid. Likewise, multiplying a rate quantile by a delay quantile should not be described as the q-quantile of accrued cost unless the profile measures or composes the joint distribution.

When quantile inputs are used, $H_j,t^admit(q)$ and $H_i,t^finish(q)$ are profile risk budgets, not deterministic maxima. The quote or profile should disclose $q$, $\gamma$, tail-overrun handling, and observed overrun reporting for each headroom convention it uses. A deterministic hard-bound profile may replace $C_latency,t^(q)$ with enforced maximum rates, enforced maximum control delay, and maximum in-flight unacknowledged ranges; in that case the profile should say that it is a hard-bound profile and define how the maxima are enforced.

For a text-only output-token profile, $U_active,t$ may contain only quoted output-token production under the selected delivery and acknowledgement profile, reducing $C_latency,t^(q)$ to output rate multiplied by the control-latency budget and quoted output-unit price. $U_active,t$ must not include raw prompt, raw output, transcript material, unquoted provider-internal work, or provider-observed units that the quote did not price. More advanced profiles should include any quoted unit that can accrue before the scheduler sees a top-up, drain, or stop decision. For speculative decoding, $C_next,t^max$ should cover the maximum accepted-token burst for the next speculative validation step. Accepted and delivered tokens are billable output only when they satisfy the selected billing boundary. Rejected draft work is provider risk unless the quote explicitly prices it under an attestation, audit, or dispute-opening profile.

The buffer is not a fee. It is a risk and latency control. It gives the provider enough authorised headroom to continue a bounded unit of inference without waiting for a payment message at every token.

Watermarks should be ordered in the same money-denominated unit and evaluated against the current disclosed metering boundary:

The intended credit-state convention is a direct function of the applicable available amount at each disclosed boundary. Before admission it is evaluated against $a_t$. Immediately after reserving a newly admitted interval it may be evaluated against $a_t^reserve(j)$ for telemetry and future-admission state. After a meter frame posts and an active bound is removed or reduced it is evaluated against $a_t^posted$. The post-reservation value does not retroactively reject the interval that was just admitted; it controls warning, drain, and later admission.

Equality is intentionally kept in the higher-credit state so that implementations do not disagree at exact boundary values. Profiles that require distinct warning and drain intervals should set $L_t > D_t > H_t^state$. Profiles may set $L_t = D_t$ or $D_t = H_t^state$, but then the adjacent state collapses: $L_t = D_t$ gives no distinct low_credit interval, and $D_t = H_t^state$ gives no distinct draining interval. Jumps across multiple thresholds take the deepest matching state directly; an implementation should not be required to pass through low_credit before entering monetary draining or credit_stopped.

Acknowledgement lag is a separate delivery-lag state, not another meaning of $D_t$. Optional warning thresholds use explicit enabled sets so omitted dimensions cannot accidentally trigger or suppress ack_lag_low. Let $W_R$ mean the range warning threshold is enabled and $W_E$ mean the exposure warning threshold is enabled:

Equality follows the same higher-state convention as monetary credit thresholds: equality at $R_low$ or $E_low$ does not trigger ack_lag_low, and equality at $R_unacked$ or $E_unacked$ remains ack_lag_ok.

If a profile does not define $R_low$, set $W_R=false$. If it does not define $E_low$, set $W_E=false$. If both warning dimensions are disabled, ack_lag_low is unreachable and the state moves directly from ack_ok to ack_lag_exceeded. Enabled warning thresholds must not exceed their corresponding stop thresholds. Top-ups recompute and may improve monetary credit state; sufficient top-ups restore credit_ok. DeliveryAck, transport backpressure, slower emission, or stopping at the disclosed delivery boundary recomputes or handles acknowledgement-lag state; sufficient acknowledgement restores ack_ok. If the next interval would exceed the quote's disclosed cost bound, the client's policy, monetary credit state, or acknowledgement-lag guard, the provider must quote again, request fresh authorisation or acknowledgement, apply the disclosed slow-consumer policy, or stop before execution enters that interval.

Acknowledgement-lag stop. If ack_lag_exceeded occurs while an output-producing interval is active, the provider must not treat the interval's planned boundary as automatically finishable. The profile must define an ack-lag stop boundary. Under the base acknowledged-billable profile, the provider closes the interval at the latest accepted DeliveryAck boundary, posts only the acknowledged billable amount to cumulative_amount_due, reports any delivered but unacknowledged range as provider-risk exposure, and treats generated but undelivered output as provider risk. The active interval's meter_status must become posted for the acknowledged portion and reduced, released, or disputed for the remaining active bound according to the profile. The provider then removes or reduces the affected $C_i^max$ from $B_active,t$, emits the terminal or reduced MeterFrame and Stop where terminal, recomputes $P_t$, $B_active,t$, credit_state, and ack_state, and carries the stop boundary, delivered-but-unacknowledged range, and meter status into FinalReceipt. A weaker delivery-boundary profile may stop at a disclosed transport boundary, but it must state which unacknowledged output, if any, can become billable and how the receipt exposes that boundary.

Credit state and acknowledgement-lag state are not execution phases. run_execution_state is a high-level lifecycle state; prefill, decode, tool units, KV hold, multimodal work, reasoning-token intervals, and scheduler-admitted accelerator intervals belong in active_admitted_intervals. They may coexist, and each active interval is allowed only while the current credit state and acknowledgement-lag state permit the next disclosed boundary.

Protocol Objects

The following objects are the minimum useful surface for an MPP-I specification.

This remains paper-level shape, not a complete wire specification. Interoperable profiles must define protocol versioning, canonical serialisation, object type tags, signature suites, domain separation, asset identifiers, network identifiers, decimal and smallest unit rules, clock skew rules, problem codes, transport mappings, settlement method mappings, and dispute opening procedures.

Signed payment/control objects should bind private inference content by digest or hiding commitment rather than carrying raw prompt, raw output, or raw transcript material. For POST inference requests, a Payment HTTP body digest or equivalent canonical request digest can bind payment objects to the private HTTP request, but a deterministic digest is not by itself a content-private commitment for low entropy or guessable content. Payment plane privacy requires a salted or blinded, domain-separated hiding commitment profile for request, delivered output, and billable event commitments. Large quotes should be referenced by quote_id and quote_hash when they are too large for compact HTTP headers; the signed policy, grants, meter frames, and receipt then bind to the digest rather than copying the full quote through every message.

Digest fields name a canonical object body; they are not included in the byte string whose digest they name. A formal profile should define InferenceQuoteBody as the quote body excluding quote_hash and envelope metadata, then compute:

InferencePolicyBody should be defined similarly, excluding policy_hash while still binding to quote_hash. Profiles may carry these hashes in an envelope, challenge parameter, reference object, or object row, but the digest field is excluded from its own digest target.

The object table below is a paper-level inventory, not a self-hashing schema. Its ``fields or bindings to specify'' column may name body fields, envelope or reference fields, and derived digest fields in the same row. A formal wire profile should split each signed object into an explicit body, envelope/reference fields, and derived digest fields, then state exactly which bytes each digest and signature covers. For auditability, the formal specification should also split this inventory into identity and binding fields, pricing and gate fields, delivery fields, evidence fields, and settlement fields.

\footnotesize

minimum_execution_buffer is the canonical name for the money-denominated minimum buffer used in the headroom rule. If an early profile or draft field uses minimum_buffer, it should be treated as an alias for minimum_execution_buffer or renamed before interoperability testing.

The base profile should establish run_id before policy signing. The simplest construction is for the provider to place an unguessable run_id directly in the executable quote. A nonce-derived construction is also workable, but the dependency order must be explicit:

1. The provider quote body contains payment_challenge_id, provider_run_nonce, quote ID, provider ID, inference target, request-commitment rule, price schedule, and expiry.
2. The quote hash is computed over InferenceQuoteBody, excluding quote_hash and envelope metadata.
3. The client or wallet chooses policy_id and computes the content-private request commitment under the quote's commitment rule.
4. Both sides derive run_id from a domain-separated hash over payment_challenge_id, quote_hash, policy_id, provider_run_nonce, and the request commitment.
5. InferencePolicyBody includes the derived run_id, policy_id, quote_hash, request commitment, provider ID, payment method, settlement destination, max spend, allowed units, and expiry. policy_hash is then computed over that policy body, excluding policy_hash itself.
6. The provider rejects any CreditGrant, DeliveryAck, MeterFrame, or FinalReceipt whose run_id does not match the selected construction.

In either construction, InferencePolicy, the genesis CreditGrant, DeliveryAck, MeterFrame, and FinalReceipt must bind the same run_id. The provider should reject a second run_id for the same quote, policy, and request commitment. Alternative profiles may allow a wallet or facilitator to create run_id, but only if it is created before policy signing and explicitly provider-bound before the genesis grant is accepted.

The initial CreditGrant is a genesis grant because it is issued before any MeterFrame or DeliveryAck exists. Each profile must define a genesis payment-state vector for that grant. The genesis vector should bind the run_id, quote, policy, request commitment, provider, claim reference or profile-defined claim-reference convention, and cumulative authorised amount, while setting meter and acknowledgement references to profile-defined genesis values such as acked_meter_frame_sequence = 0, genesis_meter_hash, null DeliveryAck sequence or hash, and an empty acknowledged delivered range. The first DeliveryAck should use the same profile-defined genesis meter-frame reference until a provider MeterFrame exists; later acknowledgements should bind the latest accepted MeterFrame sequence and hash when the profile uses that reference. Later CreditGrant messages should reference a causally accepted MeterFrame and, where acknowledged-output billing is used, the latest accepted DeliveryAck visible to the grant issuer under the profile's acceptance rule.

A formal profile should define grant acceptance under meter-frame concurrency. The grant issuer's acked_meter_frame_sequence must be non-decreasing for that issuer and run. The provider may accept a grant that references meter frame $N$ after it has emitted $N+1$, provided $N$ is within the disclosed acceptance window, is not below the provider's minimum required acknowledgement sequence for new admission, and the grant sequence, cumulative authorised amount, validity interval, policy binding, and method claimability are all acceptable. The provider should reject a grant that decreases grant sequence, cumulative authorised amount, or acknowledged meter-frame sequence; references a meter frame below the accepted replay window; is stale after terminal settlement; or is not bound to the current run, policy, payment method, and claim state. Reconnect handling should use the same cumulative monotonic rules so delayed grants can top up only the latest valid run state and cannot roll metering or settlement backwards.

Under an acknowledged-billable profile, latest_billable_output_sequence is the output boundary that may advance output amount due. Generated, emitted, transport-flushed, and signed-delivered sequences may be useful for reconciliation and slow-consumer handling, but they do not by themselves make output billable.

\footnotesize

Table~[tab:mppi-binding-chain] is a proposed future-profile binding checklist. It inherits the required object content in Table~[tab:mppi-objects]; a formal profile must state whether each field is carried directly, covered by a referenced body hash, or derived from a domain-separated commitment.

\vspace0.5em

In Table~[tab:mppi-binding-chain], the direction is explicit: the named signed object body includes or hashes the listed fields. If a row relies on quote_hash, policy_hash, or another digest rather than repeating a field directly, the formal profile must define the covered body and show that the digest commits to that field. Profiles may add fields, but they should not remove the run, quote, policy, delivery, grant, meter, claim, provider, request, payment-method, or settlement bindings that make replay and substitution attacks detectable.

A final receipt is valid only if these direct bindings and the referenced terminal objects validate against the same run, quote, policy, request commitment, provider, payment method, and claim state. A verifier should reject a receipt that presents a valid settlement reference but cannot reconcile the terminal meter frame, latest grant, terminal DeliveryAck where used, and final usage totals to the same signed lifecycle. If the HTTP Payment-Receipt header carries only a compact receipt reference, the referenced signed body must be digest-bound to the challenge, run, policy, meter frames, and settlement reference.

claim_reference_hash is payment-method neutral. A direct profile may map it to an escrow, allowance nonce, voucher channel state, or channel-state root. A facilitated profile may map it to a facilitator reservation or credit-assurance object. If a payment method does not expose a separate claim reference, the method profile should define a signed null value or equivalent claim-reference commitment under the payment-method mapping and profile identifier. A null claim-reference convention is valid only when the method profile separately defines provider-verifiable, run-scoped claimability and computes run_claimable_limit; it must not represent absent or unverifiable funding state. The requirement is that a run-bound grant is tied not only to the run and policy, but also to the claimable funding state, or explicit method-level claim convention, that makes the grant economically enforceable.

Credit grants should be cumulative, not incremental. A cumulative grant is easier to verify, easier to settle, and safer under retries. If the latest valid grant authorises 50 cents and an earlier grant authorised 30 cents, the $0.50 grant is a settlement cap for that run, not the cumulative metered amount due. A provider should accept only strictly increasing grant sequences, non-decreasing cumulative authorised amounts within policy, a run_id that is globally unique and unguessable for the chosen profile, and grants whose acknowledged meter frame sequence is acceptable under the causal replay-window rule. This prevents a valid old grant from rolling the run back to a lower authorisation after reconnect or duplicate delivery.

Final settlement should separate the collection cap, the intended collection target, gross value movement where it exists, refunds where they exist, and the amount finally retained by the provider. The cap is constrained by the latest valid cumulative authorisation, by the client policy, and by the run-scoped amount actually claimable or retainable under the selected payment method:

Here run_claimable_limit is the method-profile-computed maximum amount verifiably claimable or retainable for this run. It may be backed by escrow, an allowance nonce, channel state, a voucher state root, a facilitator reservation, a prior push payment, or another atomic method convention. A separate claimable_reserved_amount can exist inside one method profile, but it is not the generic settlement-cap term.

When gross/refund fields are used:

Derived receipt fields. Let $U_auth$ denote unused_authorisation_amount, $L_auth$ denote latest_cumulative_authorised_amount, and $S_target$ denote settlement_target_amount. unused_authorisation_amount means unused buyer permission:

It is intentionally different from unused collectible cap. Let $U_cap$ denote an optional profile-specific unused collectible cap amount, and $S_cap$ denote settlement_cap:

A profile that needs to expose unused collectible cap should name that field separately rather than overloading unused_authorisation_amount. released_run_claimable_amount is method-profile specific. Let $R_release$ denote released_run_claimable_amount and $R_claim$ denote run_claimable_limit. For escrow, reservation, allowance, or voucher methods with explicit run-scoped release, a final normal receipt may set:

If settlement, refund, reversal, dispute, or finality handling is not final, the receipt should carry a reservation release state such as not_started, partial, pending_finality, released, or disputed, and may report only the amount actually released under the selected method. Direct payment methods with no reusable reservation may omit released_run_claimable_amount or set it to a profile-defined null value.

authorisation_shortfall_reason is present only when final_metered_amount_due exceeds settlement_cap, or when the terminal reason is credit exhaustion caused by unavailable usable authorisation or claimability. It should explain the operational reason for the shortfall, such as topup_missing, topup_invalid, grant_expired, policy_limit_reached, run_claimability_limit, or facilitator_reservation_unavailable. It does not replace settlement_cap_cause, which identifies the binding cap constraint, or over_cap_cause, which explains why metered usage exceeded the cap.

Here settled_amount is status-conditioned. While settlement is non-final, it means the current net provider-retained amount visible under the selected payment method. Once settlement_status is final, it means the final provider-retained amount under that method's finality rule. FinalReceipt is the final run receipt, but settlement finality is status-conditioned. If settlement_status is final, the receipt must satisfy:

A positive over_settled_amount is therefore not valid in a settlement-final receipt. It is valid only in an explicitly non-final settlement status, such as pending_finality, pending_refund, refund_due, refunding, disputed, or invalid, as defined by the selected method profile. In those states the receipt must carry refund_due_amount, refund status, refund deadline or finality rule where applicable, and the settlement reference needed to reconcile value movement. In the base profile, refund_adjustment_amount=0 and refund_due_amount equals over_settled_amount. If a method profile permits a larger refund-due value, it must name the extra non-negative component and state whether it represents fees, release delays, disputed value, or another method-specific rule. Historical gross over-collection can still be visible through settled_gross_amount and refunded_amount; the final retained amount cannot exceed settlement_target_amount once refund finality is reached.

For methods with no gross push or refund, settled_amount can be reported directly and the gross/refund fields may be omitted. For methods where value is pushed, prepaid, escrowed, reserved, partially settled, or refunded, the receipt should also report settled_gross_amount and refunded_amount, with settled_amount computed as current net retained amount until finality and final net retained amount after refund finality. settlement_attempted_amount, where present, is scoped to the current idempotent settlement attempt or settlement reference; retries should reuse the idempotency key or issue a new attempt record rather than summing attempts into this field. The final receipt should use the canonical fields in Table~[tab:canonical-settlement-fields]. This distinction matters because cumulative authorisation is permission to collect up to a cap; a method claim is the funding state that makes the cap enforceable; settlement_target_amount is the amount the provider is entitled to try to collect; settlement_attempted_amount is attempted movement for one settlement attempt; settled_amount is status-conditioned net retained value; over_cap_metered_amount is metered value outside the settlement cap, not a collectible shortfall; and over_settled_amount is non-final value retained above the settlement target before refund finality. settlement_cap_cause should be omitted, null, or set to none for normal under-cap settlement. When settlement_cap is below final_metered_amount_due, settlement_cap_cause should identify only the binding cap constraint using a profile enum such as authorisation, policy_max_total, or run_claimable_limit. over_cap_cause should separately describe why usage exceeded the cap, with values such as provider_overrun, client_policy_stop, ack_lag_stop, latency_tail_overrun, or cancel_boundary. Settlement failure, timeout, reversal, pending finality, refund due, and retry state should be represented by settlement_status and finality fields, not by settlement_cap_cause. These states should not be collapsed into one ``unused amount'' field.

Meter frames should also be cumulative. This makes omission and replay easier to detect. A client or facilitator can reject frames with nonmonotonic sequence numbers, unexpected run_id values, unexpected policy IDs, or amount changes inconsistent with the quote. Each meter frame should state the billing boundary used for its output component. Output usage should be represented as an output delivered-sequence range; non-output usage should be represented as a separate billable-event range with event type, admitted interval, meter evidence, and quoted pricing reference.

Non-output billable-event records should carry billable_unit_type, admitted interval, pricing reference, meter evidence hash or root, evidence profile ID, and an evidence reference such as tool_receipt_hash, provider-signed assertion hash, audit log reference, attestation reference, or dispute-opening rule. MeterFrame and FinalReceipt should bind the terminal hash or root over these evidence records, not only aggregate counters.

Commitment fields need a content-private commitment profile. The exact construction belongs in the technical specification, but the paper-level rule is clear: the payment/control plane may bind meter frames and receipts to delivered units and billable events, but it must not reveal raw prompt, raw output, or raw transcript. The final receipt should distinguish delivered output commitments from billable event commitments so that usage totals and the canonical settlement fields in Table~[tab:canonical-settlement-fields] can be reconciled without exposing inference content.

Content privacy does not remove metadata risk. A profile should classify payment/control fields as header_safe, signed_body_only, encrypted_body_only, or settlement_private. Headers should carry only compact identifiers, hashes, nonces, version fields, and method hints needed for routing or authentication. Request commitments, meter evidence, delivery commitments, settlement details, and receipt bodies should be signed bodies or encrypted bodies when the selected transport allows it. Infrastructure logs and intermediaries should not store raw prompt, raw output, raw transcript, unnecessary payer/provider linkage, or unnecessary settlement linkage. Settlement references should be per-run unlinkable where the selected payment method permits it. The privacy claim is therefore content privacy under the selected commitment and transport profile, plus explicit metadata minimisation, not blanket privacy.

Initial Protocol Flow

The initial protocol flow should start conservatively.

The grant_issuer role is selected by the payment profile. In direct mode it is the client or inference wallet. In facilitated mode it is the facilitator or credit-assurance service named by the profile. The provider verifies the issuer role, grant signature, grant sequence, run_id, quote and policy binding, claim_reference_hash or profile-defined claim-reference commitment/null value, and claimability or reservation state before accepting a grant. In direct mode the provider should accept a grant without contacting a facilitator only when the selected payment method exposes provider-verifiable atomic claimability for that run.

Text-only inference is the simplest reference case for measurement, but MPP-I should not be limited to text. The protocol should support any billable unit that is explicitly quoted, metered, and receipted, including input/prefill, cached input, output, reasoning tokens, tool calls, multimodal units, KV hold time, and scheduler-admitted accelerator time. Provider-observed units and units that are not output also need an explicit provider assumption, attestation profile, or dispute-opening profile before a profile claims independent verifiability. The key measurement question is whether synchronised payment state can keep exposure hard-bounded or risk-budgeted without increasing TTFT or ITL beyond the measured profile budget.

Termination Semantics

The protocol should avoid vague pause semantics. A run has three separate state axes: run_execution_state, credit_state, and ack_state. run_execution_state is a lifecycle enum, not a list of every resource currently being billed. Concurrent prefill, decode, tool, KV, multimodal, reasoning, or accelerator work is represented by active_admitted_intervals. Profiles may collapse state names internally, but they should not collapse the meaning of payment authorisation, queueing, scheduler admission, execution, draining, acknowledgement lag, stopping, and settlement.

Metering boundaries depend on the serving stack and implementation. A provider may define boundaries such as after the next meter frame, after a configured delivered sequence range, after a per-run decode window, after an accepted speculative-token burst, or after a bounded tool, multimodal, KV hold, or scheduler-admitted accelerator interval when that unit has been explicitly quoted. The quote should disclose the policy. The key property is that buyers and facilitators can reason about unpaid admitted work under the selected risk-budget or hard-bound profile when a low-credit, drain-entry, hard-stop, or acknowledgement-lag transition occurs, and that inference stops at the next disclosed boundary when the headroom rule or delivery-lag guard fails.

A non-normative text streaming profile could meter at the smaller of $N$ delivered tokens, $T$ milliseconds, or the current per-run decode window. The same profile should define maximum buffered bytes or tokens, maximum acknowledgement-lag range, maximum decode window, maximum tool interval, and profile-handled overshoot after the last valid gate. Under that shape, unpaid admitted work after a missed top-up is hard-bounded by the disclosed cost to the next boundary in a deterministic profile, or risk-budgeted by the selected latency-risk profile, rather than by the full possible output length.

Final receipts should carry a terminal reason such as completed, client_cancelled, policy_expired, credit_exhausted, provider_failed, or provider_cancelled. Cancellation and expiry are effective at the next enforceable metering boundary unless the provider can stop sooner without violating the stream or receipt semantics. A transport profile should define Cancel, CancelAck, Stop, and terminal sequencing, including the cancellation request sequence, engine cancellation attempt, effective cancellation boundary, final billable interval, release-state requirement, and stale cancel or top-up precedence. After policy expiry, the provider must not admit a new billable interval or accept additional grants under that policy; it may only finish an already admitted bounded interval, stop at the next boundary, and settle quoted, metered units. Partial run and failed run pricing must be quoted before execution. Only delivered output included in the signed delivered sequence and acknowledgement boundary defined by the profile is billable as output. Generated but undelivered output is provider risk unless a separately quoted billable event that is not output has already been admitted, metered, and receipted. Units that are not output are billable only when the quote, meter frames, and final receipt make them explicit.

MPP Compatibility and Settlement Methods

MPP-I should be payment method flexible. The MPP outer flow provides the challenge, credential, and receipt envelope. MPP-I provides the inference lifecycle inside that envelope. The selected payment method or settlement path defines claimability, settlement mechanics, and finality assumptions.

Direct Mode

In direct mode, the client or inference wallet presents MPP-I credit grants directly to the provider in a form the provider can verify, backed by the selected MPP payment method. This avoids making a facilitator mandatory. It requires the provider to verify grant signatures, funding or claimability, replay protection, policy limits, and concurrent run claimability.

Direct mode is viable only when each run has a verifiable spend lock, escrow, nonce, channel state, provider allowance, or equivalent atomic claimability that prevents the same funds from backing two concurrent inference runs at once. A free-floating wallet signature that merely states a willingness to pay is not enough for unknown counterparties. Shared funding sources are acceptable, but each inference run needs a distinct reservation or claim path.

In object terms, direct mode should bind InferencePolicy, CreditGrant, RunPaymentState, and FinalReceipt to a claim_reference_hash or profile-defined claim-reference commitment/null value. The method profile defines whether that hash commits to escrow state, an allowance nonce, a voucher channel state root, another claimable object the provider can verify cheaply, or a signed method-level convention where no separate claim object exists. A null convention is valid only when the method-level payload still gives the provider verifiable run-scoped claimability. The same method profile should define run_claimable_limit for that construction.

Facilitated Mode

Facilitated mode introduces a payment coordinator between the wallet and provider. The facilitator can reserve funds per run, issue credit assurances that providers can verify, prevent double spend across concurrent runs, batch settlement, and provide a common wallet integration point. x402 already describes facilitators as optional services that verify payment payloads and settle payments on behalf of servers [x402facilitator]. MPP-I can use the same adoption logic while adding reservations for inference and cumulative grant semantics.

In this paper, an MPP-I facilitator is a protocol-level credit-assurance role. It may be implemented by, or layered above, an x402 facilitator, but the base x402 facilitator role is not assumed to provide reservations per run unless the chosen payment method specifies that behaviour.

Facilitated mode can provide run-level isolation when the underlying settlement method does not expose a cheap atomic reservation primitive to every provider. It is a plausible first adoption path for unknown agents and decentralised inference providers, especially where providers want a lower integration burden and wallets want a single place to enforce spend policy. That adoption path should be validated through latency, integration burden, capital efficiency, facilitator economics, and provider adoption measurements. The protocol should still support direct mode to avoid making any one facilitator category mandatory.

In facilitated mode, claim_reference_hash should commit to the facilitator's run reservation or credit-assurance object. That lets the provider verify that the grant is not only signed for the right run, but also tied to a reservation that the facilitator cannot reuse across concurrent runs.

Compatibility Mapping

Security and Abuse Considerations

MPP-I moves payment decisions closer to the serving scheduler. That improves economic control but creates a serious security surface. The base threat model should assume malicious clients, malicious providers, malicious or buggy facilitators, collusion between provider and facilitator, compromised delegated signers, network attackers replaying or reordering messages, metadata observers, stale cancel/top-up races, settlement finality or reversal failures, and denial of service attempts against accelerator capacity and serving queues.

The most important implementation rule is that payment state must gate execution. If the provider only checks payment after the serving engine has already run, MPP-I becomes a receipt format, not an execution protocol.

Product Positioning

MPP-I should be positioned as an inference-native payment profile, not as a settlement product or generic checkout flow. A clean positioning statement is:

MPP-I is a proposed MPP-compatible, inference-native payment profile for metered inference. MPP provides interoperable challenge, credential, and receipt flows. MPP-I defines the protocol mechanics for candidate interval admission, admitted-interval finishability, drain, stop, settlement, and final inference receipts.

Agents

Agents require payable inference across organisational boundaries without a human checkout step or provider-specific onboarding for every call path. The protocol must let them discover inference providers, compare price and latency, authorise bounded spend, receive auditable delivered-unit receipts, and stop at a declared boundary when budget is exhausted.

Inference Providers

Providers need to expose inference endpoints that machines can pay for at admission and during execution. They need to verify authorisation before serving-engine execution, claim payment for prefill and decode under the selected payment method, avoid streaming beyond authorised amount, and handle midstream budget exhaustion without turning payment state into an after-the-fact billing record.

Wallets and Facilitators

Inference wallets and facilitators need a standard way to represent inference spend policies and issue or verify credit grants. They can enforce maximum spend, unit prices, inference-target allowlists, delegated signing rules, run reservations, and receipt collection for autonomous clients and human users without making any wallet implementation part of the core protocol.

Where Early Adoption Should Start

The first adoption hypothesis is facilitated agent-to-provider inference, especially independent providers, inference marketplaces, decentralised provider networks, and APIs that want machine-payable distribution without bespoke commercial setup for every client. This is not a limit on adoption. Any inference provider can adopt MPP-I where machine payment, bounded spend, cumulative metering, and auditable receipts are useful.

This hypothesis should be validated by integration burden, latency overhead, facilitator economics, capital efficiency, and provider willingness to expose machine-payable inference endpoints.

Reference Implementation and Measurement

A reference implementation should validate the profile rather than limit it. Text-only inference is a useful first test case because it makes prefill, decode, delivered output, and token metering easy to inspect, but the profile surface should also represent reasoning tokens, tool calls, multimodal units, KV hold time, and scheduler-admitted accelerator time when those units are explicitly quoted, metered, and receipted.

Direct and Facilitated Profiles

A direct profile should let a client or inference wallet submit cumulative credit grants that providers can verify without a mandatory facilitator. A facilitated profile should add a coordinator that reserves funds per run, issues grants that providers can verify, prevents double spend across concurrent runs, and batches settlement when appropriate. Both profiles should use the same MPP-I quote, policy, meter frame, low-credit, drain, stop, settlement reference, and final receipt semantics.

Protocol Coverage

A reference implementation should cover the six wire objects above plus provider-local RunPaymentState. It should gate prefill on initial authorisation, gate decode on synchronised payment state, emit low-credit and drain events, stop deterministically at the disclosed boundary, and handle duplicate, lost, delayed, and out-of-order control messages without double counting. It also needs to demonstrate that the payment/control plane never carries raw prompt, raw output, or raw transcript.

Measurement

The implementation should report:

• TTFT p50/p95/p99 delta versus a baseline streaming inference call.
• ITL p50/p95/p99 delta under expected grant refresh cadence.
• Total output TPS, active sequence count, batch size or decode window size, and queue depth.
• Credit grant verification latency at p50/p95/p99/p99.9 under high-output-rate streams.
• Scheduler visibility lag between accepted grant and serving-path admission decision.
• GPU utilisation, GPU memory utilisation, and KV-cache pressure.
• Profile-bounded unpaid admitted work, including metering-boundary overshoot and tail handling defined by the profile.
• Maximum buyer authorised amount at any point.
• Number and size of meter frames and credit grants.
• Frequency of low-credit, drain-entry, and hard-stop events.
• Reconciliation between final receipt, meter frames, settlement_target_amount, and settled_amount.
• Cancellation, slow-consumer, and reconnect tests.
• Duplicate, lost, delayed, and out-of-order control-message tests.
• Maximum unpaid overshoot under induced grant delay, verifier delay, network jitter, and reconnect.

Open Questions

These questions do not change the core thesis; they define the work required to turn the paper-level proposal into interoperable profiles.

Specification Direction

The paper makes a small set of clear decisions. A formal specification should turn these decisions and the open questions above into canonical object schemas, protocol versioning, serialisation rules, object type tags, signature suites, domain separation, privacy profiles, transport profiles, settlement method mappings, dispute opening rules, error codes, and reference implementation measurements.

1. MPP-I should be specified as an MPP payment profile for inference, with inference as the proposed payment intent name and the inference execution lifecycle rules defined by the MPP-I profile. Until inference is registered or otherwise accepted by the relevant MPP or Payment HTTP process, experimental deployments should identify it as a private or provisional MPP-I profile identifier, or carry it under a registered intent through a profile-specific adapter.
2. MPP should provide the outer 402 challenge, credential, and receipt envelope. MPP-I should define the inference execution lifecycle inside that envelope.
3. The profile should define two logical planes: an inference plane for private request and delivered output, and a payment/control plane for policies, grants, meter frames, low-credit events, settlement references, and receipts.
4. HTTP/2 or gRPC independent streams are a good high-performance profile. SSE plus side-channel POST, WebSocket, and HTTP/3/WebTransport should also be compatible when they preserve ordering, replay protection, run binding, delivery acknowledgement, and privacy boundaries.
5. Transport profiles should define signed and sequenced DeliveryAck, Resume, Cancel, Stop, and terminal messages, including state vectors and race precedence.
6. The profile should define run_id creation before policy signing, including the exact dependency order for provider-created and nonce-derived identities. InferenceQuote should carry either a provider-created run_id or provider run nonce; the policy body should include the resulting run identity before policy_hash is computed; and InferencePolicy, the genesis CreditGrant, DeliveryAck, MeterFrame, and FinalReceipt should bind the same run identity.
7. Signed fields in DeliveryAck, CreditGrant, MeterFrame, and FinalReceipt should bind run_id, policy ID, quote ID where relevant, provider ID, claim_reference_hash or profile-defined claim-reference commitment/null value, sequence numbers, payment-state version where relevant, acknowledged meter frame sequence, acknowledged delivered sequence or range where output billing uses acknowledged delivery, cumulative authorised amount, cumulative_amount_due, usage totals, timing policy, settlement reference, receipt transport or reference method, and content-private commitments.
8. Reconnects, duplicate messages, delayed messages, and out-of-order messages should be handled through cumulative grants, cumulative meter frames, strictly increasing sequences, and idempotent settlement against the latest valid cumulative state.
9. Credit-grant profiles should define causal grant acceptance under meter-frame concurrency: non-decreasing grant sequence, cumulative authorised amount, acknowledged meter-frame sequence, replay-window or acceptance-window bounds, terminal-state rejection, and reconnect behaviour.
10. Grant validity, policy expiry, and settlement-method claimability should state their decision points explicitly: candidate admission, interval finish, meter posting, settlement submission, finality, or a profile-defined claimability snapshot for active admitted intervals.
11. Prefill should be priced before serving-engine execution through exact tokenisation where possible, or through a conservative bound that is corrected before execution begins. The quote should bind tokenizer version, serialisation profile, special-token policy, tool schema hash, multimodal preprocessing profile, context-window policy, and cache-hit class where relevant.
12. Headroom and top-up rules should be denominated in the selected payment method's smallest unit, using the payment synchronisation invariant plus a disclosed risk-budget or hard-bound profile that covers grant RTT, verification, scheduler visibility, retry, reconnect, and every active billable unit type that can accrue before the execution gate sees the control decision. The execution gate should also enforce a separate acknowledgement-lag state for delivered but unacknowledged output as flow-control/provider-risk exposure, not as settled billable output under the base profile.
13. Profiles should define per-run admitted intervals rather than relying on a global scheduler batch as the billing boundary. Valid intervals may include prefill admission, chunked-prefill segment, per-run decode window, accepted speculative-token burst, tool interval, multimodal interval, KV hold lease, or scheduler-admitted accelerator interval. Each interval should bind a quote line item, metering-boundary profile, unit bound, price schedule, rounding rule, and computed maximum cost \(C_j^max\).
14. Output billing should apply only to acknowledged delivered output covered by delivery and acknowledgement semantics defined by the profile plus signed metering commitments. Generated but undelivered output remains provider risk.
15. Accepted speculative tokens may be billed as delivered output once delivered under the profile. Rejected draft work should remain provider risk unless explicitly priced under an attestation, audit, or dispute-opening profile.
16. Units that are not output, such as cached input, reasoning tokens, tool calls, multimodal units, KV hold time, and scheduler-admitted accelerator time, should be billable only when explicitly quoted, metered, receipted, and covered by a declared provider assumption, attestation profile, or dispute-opening profile where independent verifiability is claimed. Non-output billable-event records should carry billable unit type, admitted interval, pricing reference, evidence profile, evidence hash or root, and any third-party receipt, provider assertion, audit, attestation, or dispute-opening reference used by that profile.
17. Cached-input quotes should distinguish committed cache hits, best-effort cache hits, and fallback misses. If a best-effort hit becomes an uncached prefill, the profile should require a corrected quote or fresh grant before the expensive prefill interval begins.
18. Final receipts should include canonical usage and cap fields: usage_totals, final_metered_amount_due, settlement_cap, and run_claimable_limit. They should also include the canonical settlement and refund fields in Table~[tab:canonical-settlement-fields], settlement_cap_cause, authorisation_shortfall_reason where applicable, claim_reference_hash or claim-reference binding, unused_authorisation_amount, released_run_claimable_amount or reservation release state, settlement_reference, settlement_status, settlement_finality, terminal DeliveryAck where used, content-private delivered unit commitments, billable event evidence commitments, and non-output evidence roots by default, not raw output or transcript material.

Conclusion

Machine payment protocols can already move value around HTTP resources. That matters for inference, but it does not solve the execution-control problem by itself. Metered inference needs payment semantics for a stateful, uncertain-cost compute exchange. The provider spends before the first token. The buyer does not know the final output length. Midstream payment failure has real operational cost.

MPP-I fills the missing layer by defining the inference execution and payment lifecycle inside an MPP payment envelope. Its core primitive is synchronised payment state: a new billable inference interval may be admitted only while $a_t$ covers the candidate admission headroom $H_j,t^admit(q)$, the candidate drain-entry threshold $D_j,t$, the acknowledgement-lag guard, and the finishability of all intervals that would be active after admission. An already admitted bounded interval may finish only while its interval-specific finish headroom remains covered at the next enforceable metering boundary. Around that primitive, MPP-I defines quotes, policies, cumulative credit grants, signed meter frames, explicit low-credit and drain states, stop behaviour, settlement references, and final receipts.

This is a pragmatic trade-off. MPP-I does not prove output quality or mandate a settlement method. It makes the payment state of an inference run explicit enough that agents and users can spend under bounded policy, providers can serve machine clients with hard-bounded exposure under deterministic profiles or risk-budgeted exposure under disclosed quantile profiles, and wallets or facilitators can enforce budgets without putting payment in the path of every token.

A focused next step is a facilitated text inference reference profile with published measurements: TTFT overhead, ITL overhead, grant verification latency, profile-bounded unpaid admitted work, maximum buyer authorisation, reconnect behaviour, and final receipt reconciliation. That profile would give builders a concrete first target while preserving the larger MPP-I thesis: MPP at admission, built for inference during execution.

References

1. Ryan, B., Moxey, J., Meagher, T., Weinstein, J., and Kaliski, S. The ``Payment'' HTTP Authentication Scheme. Internet-Draft draft-httpauth-payment-00, published June 25, 2026. Accessed June 28, 2026. https://paymentauth.org/draft-httpauth-payment-00.html
2. Moxey, J., Ryan, B., and Meagher, T. ``charge'' Intent for HTTP Payment Authentication. Internet-Draft draft-payment-intent-charge-00, published June 25, 2026. Accessed June 28, 2026. https://paymentauth.org/draft-payment-intent-charge-00.html
3. DiNovi, B., Swenberg, C., and Scott, K. EVM Charge Intent for HTTP Payment Authentication. Internet-Draft draft-evm-charge-00, published June 25, 2026. Accessed June 28, 2026. https://paymentauth.org/draft-evm-charge-00.html
4. Galabru, L., and Gitter, I. Solana Charge Intent for HTTP Payment Authentication. Internet-Draft draft-solana-charge-00, published June 25, 2026. Accessed June 28, 2026. https://paymentauth.org/draft-solana-charge-00.html
5. Machine Payments Protocol. An improved sessions experience. June 17, 2026. Accessed June 28, 2026. https://mpp.dev/blog/sessions-improved
6. Machine Payments Protocol. MPP: Machine Payments Protocol. Accessed June 28, 2026. https://mpp.dev/
7. x402. Exact: Fixed price x402 payments. Accessed June 28, 2026. https://docs.x402.org/schemes/exact
8. x402. Upto: Usage-based x402 payments. Accessed June 28, 2026. https://docs.x402.org/schemes/upto
9. x402. Batch Settlement: High throughput EVM payments. Accessed June 28, 2026. https://docs.x402.org/schemes/batch-settlement
10. x402. Facilitator. Accessed June 28, 2026. https://docs.x402.org/core-concepts/facilitator
11. NVIDIA. NVIDIA NIM LLMs Benchmarking: Metrics. Last updated April 1, 2026. Accessed June 28, 2026. https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html
12. Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., Gonzalez, J. E., Zhang, H., and Stoica, I. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023. Accessed June 28, 2026. https://arxiv.org/abs/2309.06180
13. Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C., Gonzalez, J., Zhang, H., and Stoica, I. vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention. June 2023. Accessed June 28, 2026. https://vllm.ai/blog/2023-06-20-vllm
14. Amazon Web Services. How tokens are counted in Amazon Bedrock. Accessed June 28, 2026. https://docs.aws.amazon.com/bedrock/latest/userguide/quotas-token-burndown.html
15. Parikh, S., and Surapaneni, R. Powering AI commerce with the new Agent Payments Protocol (AP2). Google Cloud Blog, September 16, 2025. Accessed June 28, 2026. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
16. Google Agentic Commerce. A2A x402 Extension. GitHub repository, v0.1.0 released September 16, 2025. Accessed June 28, 2026. https://github.com/google-agentic-commerce/a2a-x402
17. Polygon. Per-inference billing for AI APIs. Polygon Developer Docs. Accessed June 28, 2026. https://docs.polygon.technology/payment-services/agentic-payments/solutions/per-inference-billing
18. Fortytwo Network. x402Escrow. GitHub repository. Accessed June 28, 2026. https://github.com/Fortytwo-Network/fortytwo-x402Escrow
19. Ling, S., Huang, Y., Du, Y., Chen, Y., Zhou, Y., Wu, L., and Wang, C. Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments. arXiv:2605.30998, submitted May 29, 2026; revised June 22, 2026. Accessed June 28, 2026. https://arxiv.org/abs/2605.30998