A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement

Introduction Some paid HTTP requests are initiated by software agents acting on behalf of a human or organisational principal. Industry material commonly discusses this class of transaction under the term "agentic payments"; this document uses "agent-initiated transactions". This document considers the subset with three architecturally significant properties. First, the transport is unreliable in the ordinary distributed-systems sense: requests can be lost, retried, duplicated, or observed out of order, so any state-changing exchange is exposed to duplication, and a retry that creates a second task or captures a second charge is a correctness failure even though every individual message was well-formed. Second, the principal is not present: authority to spend was delegated in advance, with limits (a budget, an authorised scope, an expiry, and conditions under which a human is brought back into the loop), so the server evaluates delegated authority as data presented with the request rather than inferring it from an interactive session. Third, the server commits real cost when it fulfils a request: for request types whose fulfilment involves sourcing human work, generating an artefact, or consuming metered capacity, fulfilment side effects are expensive and not freely reversible, and a server that begins fulfilment before payment is validated can have cost extracted from it by a non-paying or unauthorised caller. RFC 9110 reserves status code 402 (Payment Required) for future use ; recent protocol work proposes wire mechanics for machine payment using that code. The "Payment" HTTP authentication scheme defines an HTTP 402 challenge that a client satisfies by paying out of band and retrying with a credential; the Machine Payments Protocol (MPP) is a vendor-maintained protocol built over that scheme; x402 demonstrated the same 402 pattern bound to stablecoin settlement; and the Agent Payments Protocol (AP2) supplies a mandate object for delegated payment authority. These specifications do not collectively define the complete server-side task model considered here. A wire scheme specifies how a challenge and credential travel, and the scheme cited here also constrains side effects on unpaid requests, retry handling under an idempotency key, and concurrent use of one credential . It does not define the asynchronous task lifecycle, delegated mandate evaluation, entitlement handling, the post-gate compensation paths, or the artefact-bound operator record considered here. Those are properties of the server's own task architecture. This document describes an architectural model that addresses those concerns by placing a gate in the task lifecycle. The model places one gate state, written g*, at which a settlement-method-neutral payment requirement is validated together with delegated authority; every path into the fulfilment region of the state machine passes through that gate, and no fulfilment side effect occurs before it. The model also uses an idempotency key to associate retries with one task, a single-use nonce to reject credential replay, and a receipt linking the task to operator-controlled authority and settlement records. A fuller formal treatment of this model appears in .

Document Status and Maturity of the Cited Protocols The intended status of this document is Informational. It is an analytical description of a model, and it deliberately contains no requirements language; BCP 14 key words are not used, and nothing in this document is a conformance target. It defines no new protocol elements and requests no registrations. The cited mechanisms have different maturity and governance models that affect implementation risk: is an individual-submission Internet-Draft. As of July 2026 it stands at revision -01 (published 18 March 2026), expires on 19 September 2026, and has no IETF working-group adoption; it is not an IETF standard. was adopted by the IETF HTTPAPI Working Group and has expired: its latest revision, -07, was published on 15 October 2025 and expired in April 2026. It is cited in this document as provenance for an established pattern, not as a settled standard. MPP is vendor documentation and a vendor-maintained specification (maintained by Tempo Labs and Stripe, launched 18 March 2026). Its maintainers describe it as an open standard; it is not the product of a standards body. x402 is an independent protocol created by Coinbase. The Linux Foundation's 14 July 2026 release announced the operational launch of the x402 Foundation and the completed contribution of the x402 protocol by Coinbase, and records that the Foundation's formation had been announced on 2 April 2026. AP2 was announced by Google on 16 September 2025 ; its specification stands at v0.2, a pre-1.0 document . The Model Context Protocol (MCP) is an application-layer tool-invocation specification, cited here only for product discovery and invocation context and not as part of the settlement layer. This document cites protocol version 2025-11-25; it is not an IETF standard.

Terminology The following terms name the objects of the model. Angle brackets denote tuples. The literals true and false represent Boolean values; Greek symbols are transliterated as Phi, eta, chi, epsilon, sigma, sigma_auth, rho, rho_pay, and Omega.

Quote (q):: The tuple q = <a, p, rho, m, sigma, d, R> recording the requesting agent a, product p, request parameters rho, frozen price m, scope descriptor sigma, deadline d, and payment requirement R. A quote states a fixed amount and currency; acceptance, authorisation, and settlement are separate events.
Mandate (M):: The delegated-authority object M = <c, a, aud, b, sigma_auth, d_lim, chi, epsilon>: issuer (principal) c, holder (agent) a, audience (intended-payee set) aud, cumulative budget cap b in a single currency, authorised scope set sigma_auth, authority expiry d_lim, contributor-criteria predicate chi, and escalation predicate epsilon. In capability terms the mandate is an attenuated capability: it represents the authority recorded in its signed fields, subject to signature validation, authenticated-holder binding, audience checks, expiry, and current mandate status.
Payment requirement (R):: The settlement-method-neutral requirement R = <amt, cur, payee, eta, scheme, t_exp> issued with the quote: amount and currency equal to the quoted price, the operator as payee, a server-minted nonce eta, the scheme name "Payment", and a requirement expiry t_exp. Exactly one R is issued per quote; where a fresh machine payment is needed, a method-specific challenge derived from R is carried by an HTTP 402 response.
Settlement method (S), Settle:: How the gate is satisfied. Settle contains payment methods (card, wallet, stablecoin), entitlements (account_balance, package_drawdown, subscription_allowance), and approved credit accounts. The model does not treat an unpaid invoice as validated payment. Settlement remains separate from the gate.
Credential, realise(S, R):: The proof a settlement method produces to satisfy a requirement: presented on retry in an "Authorization: Payment" header after a 402 challenge, or recorded directly at the gate on the entitlement path.
Nonce (eta):: A server-minted value, generated with negligible collision probability, bound into R and re-presented in the credential; it is consumed as part of a successful gate commit and never becomes fresh again.
Idempotency key (k):: A client-supplied key, stable across retries of the same logical request and namespaced per client. The key identifies the logical request; the nonce identifies the issued challenge; the gate transition consumes the nonce and binds the key to the task, and that binding remains available for later retries.
Request fingerprint:: The collision-resistant digest of the canonical request representation of C8, recorded with k before the gate and confirmed at the gate commit. The canonical-request digest of is the same object.
Activation request:: The call that presents (R, S, M) for validation at the gate, carrying an idempotency key k.
Gate (g*):: The task state pending_payment_or_plan_check: the locus of the validation predicate and the unique crossing into the fulfilment region.
Fulfilment region (Phi):: The set of post-gate states {pending_expert_match, awaiting_expert_input, needs_client_clarification, in_review, ready, delivered}. All expensive, not freely reversible fulfilment side effects occur on transitions entering or internal to Phi.
Entitlement:: The non-machine-payment way to satisfy the same gate: an existing entitlement (package drawdown, subscription allowance, account balance), presented as the settlement method whose credential realises the same R, recorded in place of a fresh machine payment.
Contributor (e):: A human contributor whose input is recorded in L and who satisfies chi_M.
Ledger (L):: An append-only record of discrete fulfilment contributions; entries are <taskId, e, inputRef, t>, where taskId identifies the task, e is the contributor, inputRef identifies the recorded contribution, and t is its timestamp.
Delivery receipt (Omega):: The operator-issued object Omega = <M, rho_pay, taskId, hashAlg, artefactHash, t, mode>. hashAlg identifies the collision-resistant hash algorithm, and artefactHash is computed over the exact delivered bytes; the other fields record the mandate, the settlement reference rho_pay, the task identifier, the timestamp, and the settlement mode. In a delivery receipt rho_pay binds the task to the payment, credit, or entitlement record accepted at the gate; the same settlement reference is reused by a compensating receipt to reconcile a capture recorded without gate acceptance.
verify_Omega:: The consistency check of a receipt against operator-controlled records: resolve taskId to the final receipt stored for that task and require the supplied Omega to equal it; recompute artefactHash over the exact delivered bytes using hashAlg and compare; resolve rho_pay against the method-specific payment, credit, or entitlement record; resolve M against the mandate registry; check the taskId binding.
F, ValidatedReq:: The partial fulfilment function F: ValidatedReq -> Artefact, with side effects recorded in L; ValidatedReq is the set of (q, S, M) triples whose requirement passed the gate. F is defined on the validated requests that reach delivered; a validated request that reaches credited_or_refunded before delivery yields no artefact, while an upheld dispute may move a task to credited_or_refunded after F has yielded its artefact. The model treats invocation of F only after the gate transition as an implementation invariant; the type notation does not enforce that ordering.
Operator:: The server-side entity that issues quotes and requirements, controls the gate, task engine, and stores, and fulfils or delivers the task.
Client:: The authenticated party that submits activation requests and holds the idempotency-key namespace. The agent acts as client on behalf of the principal.
Money:: Non-negative integer minor units paired with a currency tag. currency(x) reads the currency tag of a Money value x; the frozen price m(q) and a mandate's cap are Money values, so the budget test of authorises compares their currency tags before comparing amounts. Comparison is defined only within one currency; cross-currency comparison is undefined and is resolved by conversion at quote time, since a quote fixes one currency.
Predicates:: credentialValid(cred, R) checks the credential cryptographically and confirms payment assurance sufficient for the expected fulfilment period, or validates entitlement or credit evidence that the gate commit can reserve atomically and that resolves to an account the authenticated client may draw on under M, rather than to a client-supplied identifier alone; authorises(M, q) checks delegated authority (); fresh(eta) holds while the nonce is unconsumed; current(R, q) holds while R remains the in-force requirement issued for quote q; expired(R) holds when current_time is at or after t_exp(R); dl(q) is expired when current_time is at or after dl(q); consume(eta) atomically spends a nonce; active(M, t) holds when M is in force and has not been revoked at time t; the guard "capture recorded" holds when the task's settlement record shows funds transferred or captured out of band, as distinct from an authorisation held for later capture; validate(R, S, M) is the gate predicate conjoining these ().
CAS(k: bottom -> taskId):: The atomic compare-and-set by which the task store binds an unbound idempotency key to a task record; bottom denotes the unbound value. It succeeds at most once per key and is performed as part of the gate commit.
Term:: The terminal states {cancelled, failed, credited_or_refunded}.

Layered Architecture This section arranges the transaction path as a layered stack, places each cited mechanism on it, and states what the gate does and does not replace.

The Layer Map The stack runs top to bottom (). The access layer can expose Representational State Transfer (REST) APIs. A request descends through access, decision, and payment/settlement layers before crossing the gate. The artefact and delivery receipt return to the caller; the operator retains the audit record. Throughout this document, the operator-controlled audit record comprises L and Omega; verify_Omega checks Omega only and does not verify or bind L.

for delegated spend | +------------------------------+--------------------------------+ v +---------------------------------------------------------------+ | Product interface (access layer) | | tool-invocation surface (agent-facing) . REST/domain APIs | | (system of record) | | carries no money, decides no price; routes request inward | +------------------------------+--------------------------------+ v +---------------------------------------------------------------+ | Decision layer | | pricing price(p, rho) -> Money, frozen at quote time . | | authority check authorises(M, q) . entitlement resolution | | . attaches R to every quote; derives the 402 challenge | | from R only where a fresh machine payment is needed | +------------------------------+--------------------------------+ v +---------------------------------------------------------------+ | Payment/settlement abstraction | | one payment-or-entitlement gate, many settlement methods: | | 402 challenge-credential-receipt on top; the settlement | | method S in Settle selected beneath | +------------------------------+--------------------------------+ v +===============================================================+ | THE GATE g* (task state pending_payment_or_plan_check) | | validate(R, S, M) <=> credentialValid AND authorises | | AND current AND fresh AND NOT expired | | true => enter region Phi false => refuse | +==============================+================================+ v +---------------------------------------------------------------+ | Fulfilment system (region Phi) | | async task engine (state machine) . contributor sourcing | | against chi . append-only ledger L . | | partial F: ValidatedReq -> Artefact | +------------------------------+--------------------------------+ v +---------------------------------------------------------------+ | Result + receipt + audit | | delivered artefact . receipt Omega (verify_Omega checkable) | | . audit record . contributor payment outside this model | +---------------------------------------------------------------+ ]]> The gate g* is the point after which the modelled fulfilment side effects may begin. Everything above it prepares quotation, authorisation, and settlement evidence; everything below it is the fulfilment region Phi.

Protocol Placement The layer map assigns each cited mechanism to the function it provides. A tool-invocation protocol such as MCP makes a product discoverable and callable by an agent; AP2-style mandates record who authorised what; an asynchronous task engine fulfils; receipts and audit make the outcome checkable against operator-controlled records. In this model, none of these layers is treated as the settlement layer. Between an agent-readable product surface and paid access sits the payment/settlement layer that the access, authority, and fulfilment layers do not themselves provide: the point at which a machine presents a valid payment, the server validates it, and only then does fulfilment begin. The model places the cited protocols as follows:

The "Payment" HTTP authentication scheme and MPP.: The wire mechanism is the "Payment" HTTP authentication scheme of : the server returns 402 Payment Required carrying a "WWW-Authenticate: Payment" challenge; the client pays out of band and retries with an "Authorization: Payment" credential; on success the response can carry the scheme's "Payment-Receipt" header, a payment receipt distinct from the delivery receipt Omega; the scheme pairs that header with "Cache-Control: private". MPP is the protocol built over that scheme . In the model this pair occupies exactly one tier: the machine-payment requirement inside the decision layer, realised over a settlement-flexible abstraction. It replaces none of the other tiers. The wire challenge is derived from and bound to the payment requirement R, supplying the parameters that the scheme requires, and the credential it elicits is what the gate validates.
x402.: x402 demonstrated the 402 paid-resource pattern in practice: its settlement is crypto-native, using stablecoin transfers settled on-chain. Verification and settlement are performed either directly by the resource server or through an optional facilitator service, which may be managed, self-hosted, or run in process. In the model that binding makes x402 one settlement path among several (a stablecoin settlement method in Settle), rather than the shape of the gate itself. Its governance transition to the x402 Foundation under the Linux Foundation, announced 2 April 2026, completed with the x402 Foundation's operational launch on 14 July 2026 .
AP2.: AP2 supplies the delegated-authority layer: signed Checkout and Payment Mandates intended to provide tamper-evident evidence of recorded user instructions within AP2's trust model, with a human-not-present form carrying price limits, timing, and conditions, and a human-present form binding exact items and price. (The 2025 announcement named these Intent and Cart Mandates; the v0.2 specification restructures them as Checkout and Payment Mandates. This document uses the human-not-present versus human-present distinction without asserting term-for-term equivalence with the current specification.) In the model the mandate M is one input to the gate, alongside R. Authority is necessary but not sufficient: a validated mandate provides evidence of the authority represented in its signed fields, but does not price the work, move money, source a contributor, or deliver a result.
Adjacent layers.: The access layer (tool invocation plus REST and domain APIs backed by the system of record) standardises how an agent calls the product and carries no semantics for payment, delegated authority, pricing, or settlement. Inter-agent protocols and commerce-channel wrappers sit at the edges, relevant only where a coordinating agent or an external commerce surface is operated. These layers are named here only to fix what the gate does not replace.

Scope of the Gate Table 1 separates the gate from the access, authority, pricing, settlement, and fulfilment responsibilities around it. Requirement Layer that owns it Agent can call the product Access layer (tool invocation / REST) Client can buy a product The payment gate (this model) Principal authorises delegated spend Mandate M (AP2-style authority) Price is calculated and frozen Pricing engine in the decision layer Entitlement already covers the request Account/entitlement resolution Money actually moves Settlement method in Settle Task is fulfilled Task engine (state machine, region Phi) Contributor inputs are managed Fulfilment workflow + ledger L Result is delivered Artefact generation F Transaction is auditable Receipt Omega + audit record

The Gated Exchange On the wire, the model's transaction is a seven-step exchange gated on a single validation. Request. The agent calls a product or quote endpoint, presenting M and an idempotency key k that remains stable for every retry of this logical request. On the machine-payment path the server records only the challenge state for that request: k, the authenticated client, a collision-resistant digest of a canonical encoding of all processing-relevant request fields, and the resulting quote. That record is not a task record, and no task identifier exists before the gate commit; reuse of k with different data is rejected. Quote plus requirement. The pricing engine freezes the price and the decision layer emits the quote q with its requirement R. If a fresh machine payment is needed, the server returns 402 Payment Required carrying a method-specific "WWW-Authenticate: Payment" challenge derived from and bound to R, which supplies the parameters that the scheme requires; R itself remains the model's internal, settlement-method-neutral requirement. If an entitlement may cover q, the server returns no 402, and the client presents entitlement evidence in step 3 for validation and atomic reservation at the gate in step 5. Obtain payment evidence. The agent obtains evidence accepted by the selected payment path. The task record distinguishes transfer, capture, authorisation for later capture, and entitlement coverage; these states are not interchangeable. Retry with credential. The agent retries the original request, carrying the credential in an "Authorization: Payment" header and its idempotency key. Validate (the gate g*). The server evaluates validate(R, S, M); the nonce binds the credential to this specific challenge, and a stale or expired challenge fails closed. Activate and return a handle. On true, and only on true, the task engine enters Phi; the server returns a task identifier. Receipt and audit. The gate commit of step 6 durably recorded the settlement reference rho_pay before entry to Phi; the server returns that reference, and constructs and returns the artefact-bound Omega at delivery. Steps 2, 4, and 5 establish the challenge, retry, and validation sequence: the challenge in step 2 names the price and the nonce, the retry in step 4 satisfies exactly that challenge, and the gate in step 5 admits the request to Phi only on full validation. Because eta is bound into R and re-presented in the credential, a credential cannot be replayed against a different challenge; the separate idempotency-key binding supports server-side idempotency ().

Formal Objects and the Validation Predicate This section fixes the objects the state machine's guards refer to. The model is implementation-agnostic: it fixes the properties that hold and leaves their realisation to the implementing service.

Quotes and Pricing At quote creation, the decision layer returns a price, scope descriptor, and deadline. The quote q = <a, p, rho, m, sigma, d, R> records the requesting agent so authority can be checked against it. C1 () freezes m(q), the scope, and the deadline for the life of that quote; a later quote may reflect different inputs or pricing state.

Mandates and Authority Cumulative committed spend under a mandate is spent(M), the sum in currency(cap(M)) of m(q) over quotes committed under M, with the empty sum equal to zero in that currency; spent(M) is monotonic, so refunds and credits do not reduce it or restore mandate capacity, and replacement capacity requires a new or amended mandate outside this model. A quote is committed when its task crosses the gate. The accessors read tuple components by position: agent(q), scp(q), dl(q), m(q), and R(q) read a, sigma, d, m, and R of q; issuer(M), holder(M), audience(M), cap(M), sigma_auth(M), and d_lim(M) read c, a, aud, b, sigma_auth, and d_lim of M; payee(R), eta(R), and t_exp(R) read payee, eta, and t_exp of R. The predicate requesterAuthenticatedAs(x) holds when the authenticated client identity is x. The budget test is total: withinBudget(M, q) is false when currency(m(q)) differs from currency(cap(M)), and is otherwise the truth value of spent(M) + m(q) <= cap(M) evaluated in that currency. Authority alone is:

requesterAuthenticatedAs(holder(M)) AND holder(M) = agent(q) AND payee(R(q)) is in audience(M) AND scp(q) is in sigma_auth(M) AND withinBudget(M, q) AND current_time < dl(q) AND dl(q) <= d_lim(M) AND active(M, current_time) ]]> Authority and escalation are two separate predicates, both evaluated at the state pending_authority, with escalation taking precedence. For a mandate M, chi_M(e) evaluates its contributor-criteria predicate for contributor e, and epsilon_M(q) evaluates its escalation predicate for quote q. The predicate epsilon_M(q) is not a conjunct of authorises and is checked first. When epsilon_M(q) is true the operator records re-approval bound to M, q, the authenticated approver, and the approval time before the task can reach the gate; the task does not advance automatically (C6). The contributor-criteria predicate chi_M is likewise not part of authority; it constrains fulfilment through the ledger invariant (C4), and a chi_M failure surfaces inside the fulfilment region as the no-qualifying-contributor transition, not as an authority failure.

Payment Requirement, Settlement, and Validation The requirement R is issued at quote time and is settlement-method-neutral. The map from quotes to requirements is total and injective: it issues exactly one R per quote, and no two quotes share a requirement. Therefore q(R) denotes the unique quote whose requirement is R. How money moves is a separate concern: a settlement method S realises R by producing the credential realise(S, R). The settlement method affects validation through realise: the same R admits different credentials under different settlement methods, and a method that cannot produce a valid credential fails the credential-validity conjunct. R is settlement-method-neutral at the model boundary; for a particular wire exchange the selected method determines the challenge and credential that realise it. On the entitlement and credit paths the evidence is not self-authenticating, so the gate resolves it to an account the authenticated client may draw on under M; presenting another principal's identifier fails the credential-validity conjunct. The gate predicate conjoins credential validity, authority, active-requirement status, nonce freshness, and temporal validity:

credentialValid(realise(S, R), R) AND authorises(M, q(R)) AND current(R, q(R)) AND fresh(eta(R)) AND NOT expired(R) ]]> Validation fails closed on any conjunct, and the wire response distinguishes the class of failure. A payment credential that fails verification follows the 402 retry path. A credential that verifies but does not satisfy the mandate (over budget, outside the authorised scope, past the authority expiry, or presented by the wrong holder) is refused without a fresh payment challenge; under that refusal is a 403 response. Both outcomes fail closed and admit no fulfilment side effect. A successful validation consumes the nonce atomically: after consume(eta(R)), fresh(eta(R)) is false. Nonce consumption makes the requirement non-repeatable; the task transition and C7 prevent a second gate crossing. The authorises conjunct at settlement time re-asserts authority already established at pending_authority; it is a defensive re-check because budget availability and mandate status may have changed in the interim, not a second authority gate. Escalation is resolved earlier, at pending_authority; contributor criteria are enforced inside fulfilment; neither is checked at this gate.

Fulfilment, Ledger, and Receipt ValidatedReq is the set of (q, S, M) whose requirement passed the gate, and F denotes fulfilment processing for a validated request; its artefact and ledger effects are represented by task-state transitions. The restriction of F to gated requests is an implementation invariant, which is what ties the safety argument of to a successful validation. The receipt Omega = <M, rho_pay, taskId, hashAlg, artefactHash, t, mode> binds, in one verifiable record, who authorised (M), what was paid (rho_pay), which task (taskId), and exactly which artefact (artefactHash, computed over the exact delivered bytes under the algorithm named by hashAlg). The mode field records the settlement mode as executed, including test or mock modes in non-production deployments; when an entitlement satisfied the gate, mode records the entitlement path (for example, package drawdown); the receipt structure and verify_Omega semantics are unchanged. The receipt gives the operator a structured consistency check across the delivered artefact and its own records; it does not provide operator-independent evidence.

The Task State Machine The task lifecycle is described as a labelled transition system T = <Q, ->, q0, Term> over control states; the payment, budget, and receipt effects associated with transitions are stated in prose alongside the guards. The states appear in , the transitions in , and draws the machine.

States State Meaning draft request captured; not yet priced quoted price m, scope sigma, deadline d, and requirement R issued accepted client accepts the quote pending_authority resolve authority + escalation (pre-gate); no fulfilment cost pending_payment_or_plan_check GATE g*: validate payment credential or entitlement evidence pending_expert_match (Phi) sourcing contributors satisfying chi_M awaiting_expert_input (Phi) contributors adding contributions to ledger L needs_client_clarification (Phi) blocked on a clarifying answer during fulfilment in_review (Phi) aggregation, validation, quality review of inputs ready (Phi) artefact generated; receipt Omega being constructed delivered (Phi) artefact plus Omega returned to the agent cancelled terminated before crossing the gate (no fulfilment cost incurred) failed unrecoverable system fault (cross-cutting) credited_or_refunded compensation obligation and selected remedy recorded against rho_pay The start state is q0 = draft. Term = {cancelled, failed, credited_or_refunded}. delivered is a completed fulfilment state with one possible transition, on an upheld dispute, to credited_or_refunded. credited_or_refunded records a compensation obligation and the remedy selected against rho_pay: a refund returns funds, while a credit leaves the charge standing and grants offsetting value. It does not assert that the settlement-side remedy succeeded; a separate settlement result records the outcome, and a compensating receipt written against rho_pay links the obligation and its result ().

Level Function, Gate, and Fulfilment Region A pipeline-position map orders the happy path and isolates the gate. The level function is defined on the eleven pipeline (non-exception) states only; the three exception terminals carry no level and are not in Phi:

The gate is g* = pending_payment_or_plan_check, at level 4. The fulfilment region is Phi = {states of level 5 or above} = {pending_expert_match, awaiting_expert_input, needs_client_clarification, in_review, ready, delivered}. The expensive, not freely reversible side effects of fulfilment (committing contributor sourcing, soliciting and recording paid contributions, generating the artefact) occur only on transitions entering or internal to Phi. Property 1 relies on one structural condition, that the only edge from outside Phi into Phi is the gate edge:

pending_expert_match ]]> Authority resolution and escalation happen strictly before the gate, at pending_authority, and resolve only to the gate state on approval, to cancelled on refusal or decline when no capture is recorded, or to credited_or_refunded on refusal or decline when a capture is recorded; none of these exits enters Phi. The mid-fulfilment state needs_client_clarification is reachable only from within Phi (from awaiting_expert_input): an intra-Phi edge, not an entry.

Transitions Guards are necessary preconditions and, for each state, mutually exclusive under the convention that expiry is evaluated before client events and events are processed one at a time. The deadline rows apply only from quoted onward, since draft has no quote and therefore no dl(q). epsilon, authorises, and chi_M are evaluated on the in-force (M, q). From Guard / event To draft submit quoted draft abandon cancelled quoted accept AND NOT expired(R) accepted quoted (reject OR expired(R)) AND no capture recorded cancelled quoted (reject OR expired(R)) AND capture recorded credited_or_refunded accepted begin authority check pending_authority pending_authority NOT epsilon AND authorises g* pending_authority NOT epsilon AND NOT authorises AND no capture recorded cancelled pending_authority NOT epsilon AND NOT authorises AND capture recorded credited_or_refunded pending_authority epsilon AND human re-approves AND authorises g* pending_authority epsilon AND (human declines OR NOT authorises) AND no capture recorded cancelled pending_authority epsilon AND (human declines OR NOT authorises) AND capture recorded credited_or_refunded g* validate = true (GATE) pending_expert_match g* validate = false AND no capture recorded cancelled g* validate = false AND capture recorded credited_or_refunded pending_expert_match contributor e with chi_M(e) found awaiting_expert_input pending_expert_match no qualifying contributor credited_or_refunded awaiting_expert_input input appended to L awaiting_expert_input awaiting_expert_input clarification required needs_client_clarification awaiting_expert_input inputs sufficient in_review needs_client_clarification answer received awaiting_expert_input needs_client_clarification timeout OR withdraw credited_or_refunded in_review review passed ready in_review unrecoverable defect credited_or_refunded ready Omega constructed and written delivered delivered dispute upheld credited_or_refunded any state from quoted through g* dl(q) expired AND no capture recorded cancelled any state from quoted through g* dl(q) expired AND capture recorded credited_or_refunded any Phi state except delivered dl(q) expired credited_or_refunded Three cross-cutting notes. First, the terminal failed is reserved for an unrecoverable system fault, which can terminate any task that has not reached delivered, cancelled, or credited_or_refunded; this family of fault edges is omitted from the per-state rows for readability. A fault edge from a state in Phi targets credited_or_refunded, because the gate commit has already recorded an accepted payment, credit, or entitlement reference that requires reconciliation. Before the gate, a fault edge targets failed when no capture is recorded, and targets credited_or_refunded when a capture is recorded. Both failed and credited_or_refunded are outside Phi, and the model does not represent whether the later settlement-side refund, credit, or entitlement reconciliation itself succeeds. Second, a no-qualifying-contributor outcome is a post-gate business outcome and routes to credited_or_refunded (the client has paid; the charge is reconciled), not to failed. Third, validation failure before funds move cancels the task. If the credential records funds already captured, failure routes to credited_or_refunded and reconciles the settlement against rho_pay. A fresh wire challenge () begins a new payment attempt; the wire scheme does not tie that attempt to this model's task machine. In this model the key k remains claimed by the terminated request's challenge record or its tombstone (C8), so a new attempt proceeds as a new activation under a fresh idempotency key against a new quote.

quoted --> accepted --> pending_authority | | | | | abandon | reject / refused/ | | authorised / | | expired(R) declined | | re-approved v v v v cancelled <--+----------------------+ +-----------------+ ^ | g* = pending_ | | validate = false, no capture | payment_or_ | +-------------------------------------+ plan_check | +--------+--------+ | validate(R, S, M) = true (the only edge from outside Phi into Phi) =================================================|=========== fulfilment region Phi (level >= 5) | . +-------------------------------------------+ . . v . . pending_expert_match --- no qualifying contributor ---+ . . | contributor e with chi_M(e) = true found | . . v | . . awaiting_expert_input <--+ (self-loop: contribution | . . | | |___________| appended to L) | . . | | | . . | | clarification required | . . | v | . . | needs_client_clarification | . . | | answer received: back to | . . | | awaiting_expert_input | . . | | timeout / withdraw ---------------------+ | . . | inputs sufficient | | . . v v v . . in_review --- unrecoverable defect ----> credited_or_ . . | review passed refunded . . v ^ . . ready --- Omega constructed and written --+ | . . v | dispute . . delivered -+ upheld . . . ............................................................ ]]> A system fault can terminate any task that has not reached delivered, cancelled, or credited_or_refunded; the resulting edge targets failed only before the gate with no capture recorded, and targets credited_or_refunded otherwise. Both are outside Phi. credited_or_refunded is drawn inside the frame only for layout. The fault edges, the dl(q) deadline edges, and the edges to credited_or_refunded on a recorded capture (from quoted on rejection or requirement expiry, from g* on validate = false, and from pending_authority on an authority failure or declined escalation) are omitted from the figure.

Activation Requests, Keys, and Nonces The gate transition is performed by an activation request: the call that presents (R, S, M) for validation. Each activation request carries an idempotency key k, client-supplied, stable across retries of the same logical request, and namespaced per client. The task store binds k to the task by an atomic compare-and-set CAS(k: bottom -> taskId) that succeeds at most once per key (C8), performed as part of the successful gate commit. On the 402 path the pre-gate record carrying k is challenge state rather than a task record; the credential retry carries the same k and is routed to that record. The key k identifies the logical request; the nonce eta identifies the issued challenge. The gate transition, at most one per task, atomically binds k to the new taskId, confirms it against the canonical-request digest recorded with the challenge, consumes eta(R), commits spent(M), atomically reserves or consumes any finite entitlement, records the accepted payment, credit, or entitlement reference, and enters Phi. A request carrying an existing k is first routed to the record bound to it, the challenge record before the gate commit and the task afterwards; only a completed gate commit bypasses revalidation. If these effects span stores, the implementation requires a documented recovery protocol that blocks entry to Phi until every partial outcome is reconciled. This document does not specify that protocol and does not assume that an external settlement can be reversed. On the entitlement path of , where no 402 retry occurs, the post-quote request that presents (R, S, M) serves as the activation request and carries k. The idempotency-key discipline is established practice on payment-initiating HTTP interfaces, and a generic header-field form was drafted in the HTTPAPI Working Group as , which has since expired () and which documents deployed interface patterns. This document cites that draft as provenance for the discipline the model binds to its gate, not as a standard; what the model adds is the binding of the key to the payment gate specifically, confirmed by the same gate commit that consumes the nonce.

Well-Formedness Constraints and Operating Assumptions This section states the eight well-formedness constraints and the operating assumptions under which the four properties hold.

Constraints The properties of are statements about well-formed runs, where well-formedness is the following eight constraints:

C1 (price-freeze):: A task activates only at the price of its issued quote; any change to the product or parameters requires a new quote and a new R.
C2 (scope):: The quote's scope descriptor is in the mandate's authorised scope set.
C3 (deadline):: The quote's deadline does not exceed the mandate's authority expiry.
C4 (contributor criteria):: Every ledger entry bound to a task under mandate M is from a contributor satisfying chi_M.
C5 (authority/budget):: Committed spend plus the quoted amount does not exceed the mandate's cap.
C6 (escalation):: When epsilon_M(q) is true, the task is routed to human re-approval at pending_authority, pre-gate, and is never auto-fulfilled.
C7 (single requirement):: Exactly one requirement R is issued for each quote. A task has at most one current, unconsumed R. After R expires or is invalidated, continuing requires a new quote, and no R is issued after the task crosses the gate.
C8 (atomic activation and idempotency):: A digest of a stable, versioned canonical representation covering every field that affects quotation, authority, settlement, and fulfilment is recorded with k before the gate, and the store binds k to taskId at the gate commit; the representation and digest algorithm are deployment obligations. Reuse with different request data fails. At activation, the following form one recoverable transaction: binding k to taskId, confirming the recorded digest, consuming eta(R), committing spent(M), atomically reserving or consuming any finite entitlement, recording the accepted payment, credit, or entitlement reference, and entering Phi. Requests carrying k after that transaction return the stored state without revalidating R. The binding or a non-reusable tombstone remains available for at least the longest period in which the operator accepts a retry or permits settlement of R. After that period, the old key is rejected rather than allowed to select a new task.

C2, C3, and C5 are conjuncts of authorises; C1 and C7 are enforced by the quote/requirement issuing map and the task engine; C4 by the ledger invariant; C6 by pre-gate escalation routing; C8 by the task store's atomic activation transaction.

Assumptions The properties hold within the model under the following named operating conditions. Each is checkable, and each names what would have to be re-established if a deployment context differs. Mandate authenticity: the mandate and payment credential are cryptographically verifiable, and credentialValid(cred, R) is evaluable by the operator without trusting the calling agent; authority rests on signature verification, not the agent's assertion. Deterministic pricing: the pricing function returns one value for the product, parameters, and pricing state at quote time; challenge expiry bounds the window in which a frozen price is honoured. All components participating in the gate commit use a consistent time source and boundary convention for t_exp, dl, and d_lim. Gate-before-fulfilment is enforceable: the operator controls the ordering of its own task state machine, so no transition into Phi occurs before the gate is satisfied. This is an invariant of the operator's own task engine, not of any external protocol, and it holds regardless of settlement method. Contributor supply and deadlines: lack of a qualifying contributor leads to credited_or_refunded. Expiry of dl(q) before the gate leads to cancelled when no capture is recorded, and to credited_or_refunded when one is; expiry after the gate and before delivery leads to credited_or_refunded. These deadline edges are evaluated before other events. Hash collision-resistance: hashAlg identifies the hash algorithm and artefactHash is computed over a stable byte representation of the delivered artefact using that collision-resistant hash, making substitution of a different artefact computationally infeasible under the assumed hash security. Idempotency keys are client-supplied, stable, retained at least as long as a payment can be retried, and bound to a request fingerprint: a retry within that period carries the same key, so the retry properties apply when client retries cause duplicate processing. Receipt and ledger integrity: the ledger L is append-only and the receipt store is durable and tamper-evident, so unauthorised rewriting is detectable; durability alone does not provide integrity. Record identity and final-receipt cardinality: taskId identifies exactly one task record; rho_pay identifies exactly one record within its method-specific payment, credit, or entitlement store; and the receipt store accepts at most one final Omega per taskId. Gate-commit integrity: the operator mints nonces with negligible collision probability; the properties are conditional on no nonce collision occurring. The gate-commit transaction of C8 occurs as one atomic or recoverably journalled operation; a crash cannot commit only a subset of its effects. A consumed nonce never returns to fresh. Budget accounting: spent(M) is committed atomically with the gate transition, so concurrent activations under one mandate serialise against the cap and cannot jointly exceed it.

The Four Properties Within the model, the following four properties are conditional invariants: they depend on the constraints and operating assumptions of and are not guarantees supplied by the cited protocols. Throughout, an execution trace is a finite path from draft respecting the guards. Trust boundary. These properties are guarantees against a misbehaving or compromised client side: an agent that replays a consumed challenge, reuses a key with different request data, presents a forged or expired credential, attempts to spend outside its mandate, or retries in a way that could otherwise cause duplicate processing. They are not guarantees against the operator itself. The operator runs the task engine, the nonce store, the task store, the ledger, and the receipt store, so gate-before-fulfilment is an invariant the operator enforces on its own execution, not a property an external party could compel. An external party can recompute the artefact hash and check only operator records to which it has access; the model provides no operator-independent evidence. Adversarial contributors are outside the four payment-gating properties. Deployments still need to authenticate contributors, limit access to task data, validate contributed inputs and artefacts, and protect ledger and receipt integrity from the fulfilment path. In fair-exchange terms the model does not solve fair exchange in the adversarial sense: strong fair exchange is known to be unattainable without a trusted third party , and here the operator, one of the parties to the exchange, is trusted. The gate enforces ordering between payment assurance and fulfilment; it does not provide fair exchange between mutually distrustful parties.

Property 1: Gate-before-Fulfilment Safety Statement. In every reachable trace, no side effect of the fulfilment function F occurs unless validate(R, S, M) = true held at that or an earlier step. Argument (by construction over the transition table). (a) Phi excludes the start state: draft has level 0, below 5. (b) Enumerating the in-edges of Phi from : the only states outside Phi with edges that could target Phi are the pre-gate states, draft through g* (level 4 or below); the exception terminals have no out-edges; and the cross-cutting fault edges target failed or credited_or_refunded, neither of which is in Phi. Inspection shows that the set of edges from outside Phi into Phi is the singleton {g* to pending_expert_match}, guarded by validate(R, S, M) = true. In particular pending_authority resolves only to g*, cancelled, or credited_or_refunded, all outside Phi, and needs_client_clarification is entered only from awaiting_expert_input, an intra-Phi edge. (c) Every other edge with target in Phi has its source already in Phi. (d) Hence any trace reaching a state in Phi contains the gate step taken under validate = true. Since the side effects of F fire only on transitions entering or internal to Phi, each occurs no earlier than that successful validation. The guard is evaluated atomically with the transition, and consume(eta(R)) makes fresh(eta(R)) false, so no trace leaves Phi and later re-enters it: re-entry could occur only through the gate edge, whose freshness conjunct cannot hold again for this task (C7).

Property 2: Idempotency under an Idempotency Key Statement. While the C8 binding is retained, for activation requests in one client namespace that carry the same key and request fingerprint, at most one task record is selected. Later requests observe the same record; reuse with a different fingerprint is rejected. This property does not establish settlement-side charge uniqueness. Argument. The gate commit for the first activation carrying k runs CAS(k: bottom -> taskId) (C8), which succeeds and binds exactly one task record to k. On the 402 path the pre-gate challenge record carries k, the credential retry maps to that record, and the gate commit it drives performs the single CAS for k. A concurrent retry that does not win the CAS is routed to the task created by the winning commit once its request fingerprint matches. Any request carrying k after the gate commit finds the outcome recorded; the server returns the existing taskId and settlement reference rho_pay (and, after delivery, the same Omega) without re-invoking F or repeating the gate commit. Whether a settlement method can create more than one transfer, authorisation, or capture is outside this property and requires a settlement-side uniqueness guarantee. Hence a retained key selects at most one task record and one gate commit. Later requests address that evolving record.

Property 3: Single Acceptance per Payment Requirement Statement. For any issued requirement R, at most one successful gate transition consumes R. This model does not prevent multiple out-of-band payments or settlement-side charges unless the selected settlement method provides a uniqueness guarantee bound to R. Any subsequent compensation issues a refund or credit against the settlement reference rho_pay. Argument. (a) The issuing map produces exactly one R per quote, with a nonce generated with negligible collision probability, and by C7 at most one unconsumed R is in force per task. (b) Validation consumes the nonce atomically; thereafter fresh is false, so re-presenting the same proof cannot produce a second successful gate transition. Nonce consumption alone does not prove that only one transfer, authorisation, or capture occurred. (c) A second, distinct R requires a new quote (C1 and C7); no replacement requirement is issued for the existing quote or after the task crosses the gate. (d) By Property 2, the keyed request produces at most one task selection and one gate commit; this does not establish settlement-side charge uniqueness. Combining (a) through (d): at most one successful gate transition consumes any issued R; this constrains server activation only, and settlement idempotency remains a separate property of the selected method. A later credited_or_refunded transition issues a refund or credit against rho_pay; it never captures a second charge.

Property 4: Operator-Checkable Audit Record Statement. Every task in state delivered has an operator-issued receipt Omega whose fields can be checked against the operator-controlled mandate, settlement, task, and receipt stores under the assumptions of . This property does not provide evidence against a dishonest or compromised operator. Argument. The only in-edge to delivered is from ready, guarded by the construction and writing of Omega; hence delivered implies Omega exists. Omega embeds hashAlg and artefactHash (binding the exact artefact under the hash algorithm named by hashAlg), rho_pay (identifying the settlement record), taskId, and M. Under the record-identity and final-receipt-cardinality assumption of , the final delivery receipt is immutable. Compensation records are separate append-only records linked to rho_pay and, where a delivery receipt exists, to Omega; they neither replace Omega nor violate final-receipt cardinality. verify_Omega resolves taskId to the stored final receipt and requires equality, recomputes artefactHash over the exact delivered bytes using hashAlg and checks equality, resolves rho_pay against the method-specific payment, credit, or entitlement record, resolves M against the mandate registry, and checks the taskId binding against the task store; these checks depend on the assumptions of and on the operator-controlled stores.

Composition Together, the scoped properties state that modelled fulfilment effects follow a successful gate transition (Property 1), a correctly keyed request selects at most one task record (Property 2), one requirement can produce at most one successful gate acceptance (Property 3), and delivery creates an operator-controlled record (Property 4). Bounded delegated spend is not a separate proven property: non-exceedance of the mandate cap is delivered by the budget conjunct withinBudget of authorises, which enforces C5, together with the budget-accounting assumption of , under which concurrent activations serialise against the cap. They do not establish payment-fulfilment atomicity, settlement-side charge uniqueness, or operator-independent verification.

Operational Considerations

Settlement flexibility at one gate.: The payment requirement R is settlement-method-neutral, so settlement unavailability does not propagate into the task machine. When no method in Settle can realise R for a given caller, jurisdiction, or account, the request does not pass the gate and, by Property 1, no modelled fulfilment side effect occurs in the interim; C1 governs product or parameter changes, not settlement-method changes, and because R is settlement-method-neutral a method change reuses the same R. By C7 no replacement requirement is issued for an unchanged quote, so a new R follows only from a new quote. Settlement availability is an operating assumption, not a property guaranteed by the architecture: as of mid-2026 the Stripe implementation of MPP gates acceptance by geography and legal entity , one reason the model does not depend on any single settlement method.
Entitlement at the same gate.: An existing entitlement satisfies the same gate state that a fresh machine payment does: the entitlement is the settlement method that realises R, so the same validation runs and the same nonce is consumed, with no fresh machine payment. The receipt structure and its verification semantics are unchanged, with the mode field of Omega recording the entitlement path.
Interaction shape.: This model covers asynchronous, human-sourced task creation via POST, not paid content retrieval. After the gate admits the request, the task enters Phi and the server returns a task identifier while fulfilment proceeds; a repeated call under a retained idempotency key returns the same task or, after delivery, the stored artefact and receipt. Settlement-side charge behaviour remains governed by the selected settlement method. The safety argument in is stated for the asynchronous task shape; paid content access would require the analogous guarded transition from the gate to a ready state, validated by the same predicate.
Authorisation and capture.: Some settlement methods separate authorisation from capture. Deferring capture until delivery introduces authorisation-expiry and capture-failure cases that this model does not represent. A capture that becomes effective after the task has already terminated is likewise reconciled settlement-side, outside the model. The properties in apply only when gate validation secures the quoted amount for the expected fulfilment period; otherwise explicit reauthorisation, capture-failure, and compensation transitions are required.
Regulatory scope.: Gate validation is a technical check within the model. It does not establish legal authority or discharge authentication, disclosure, sanctions, tax, consumer-protection, refund, chargeback, or other scheme and regulatory obligations.
Pre-gate eligibility.: Deployments commonly run eligibility controls beyond authority (conflict, confidentiality, or topic policy). In the model these compose as pre-gate predicates resolving alongside authority and escalation at pending_authority, never inside Phi.
Dependency on in-progress specifications.: The wire scheme underneath the gate is a live individual-submission Internet-Draft (), and the protocol above it is vendor documentation. Implementations can limit this dependency by pinning the implemented revision and reviewing the pinned revision when it expires or is superseded; treating header names and challenge shapes as versioned against the pinned revision; keeping gate semantics owned by the server's own decision layer and task machine, not delegated to the wire scheme; and keeping settlement flexible so no single settlement method is indispensable. These controls limit, but do not remove, the implementation's dependency on the pinned payment-scheme draft revision: the gate-before-fulfilment discipline, the idempotency and challenge-binding rules, and the durable receipt store hold regardless of how that payment-scheme draft evolves.

Security Considerations This document describes a model rather than a protocol, so the considerations below concern the model and the conditions under which its properties hold. Every activation and delivery path, including the entitlement and credit paths that use no machine-payment wire exchange, needs transport confidentiality, integrity, and server authentication; object signatures alone supply none of these. Credentials and receipts need sensitive-data handling on every path. Deployments using the referenced Payment authentication scheme also inherit the security considerations of , including its transport protection, credential handling, challenge binding, intermediary behaviour, caching, and denial of service.

Replay.: The nonce eta is bound into the requirement R and re-presented in the credential, so a credential cannot be replayed against a different challenge. Validation consumes the nonce atomically and a consumed nonce never returns to fresh, so replay of a consumed nonce fails the freshness conjunct. A stale requirement is rejected via expired(R) and forces a re-quote; a fresh R carries a fresh nonce.
Double charge.: One requirement per quote, the single-active-requirement constraint (C7), and the price-freeze constraint (C1, which forces a superseding quote for any parameter change) combine with atomic nonce consumption to bound gate acceptance at one requirement per task (Property 3). Retries under a stable idempotency key are absorbed by the compare-and-set (C8) at the gate, not inside the fulfilment region, so a duplicate request never starts a second fulfilment execution; keys are scoped to an authenticated client; possession of k alone does not authorise access to the bound task or receipt. A client that retries without a stable key can create and pay for a second task. Nonce consumption prevents reuse of one payment requirement; it does not provide logical-request idempotency across different keys.
Delegated authority and escalation.: Authority acceptance precedes gate acceptance, and gate acceptance precedes fulfilment. Because settlement happens out of band, a transfer or capture can be recorded before authority resolution completes; the capture-recorded exits reconcile that case, so the model does not order the movement of funds against authority resolution. An unauthorised purchase attempt by a misbehaving agent is an authority failure, caught at pending_authority by authorises(M, q) before the payment gate is reached. The escalation predicate is evaluated first and takes precedence; when it holds, the task requires human re-approval, does not advance automatically, and pending_authority never resolves into Phi. Within this model, bounded delegation limits the amount committed through conforming gate transitions to the mandate cap; it does not bound settlement-side duplicate charges or non-monetary harm. The authority re-check at the gate is defensive, and authority rests on signature verification of the mandate. Authority is evaluated at pending_authority and re-checked at the gate, and not again inside Phi, so revocation of M after the gate does not stop fulfilment or delivery and does not restore spent(M). A deployment that needs revocation to take effect mid-fulfilment adds an explicit in-region check and a compensation route.
Denial of cost.: The inverted pattern, in which contributor sourcing or other operational cost precedes the gate, lets a non-paying or unauthorised caller extract cost from the server. The transition model places matching, ledger writes, and artefact generation after gate validation. Before the gate, a caller can still force quote creation, nonce issuance, challenge-state recording, and credential checks; admission control, authenticated quotas, bounded retention, and rate limits remain deployment concerns. The model also does not remove authorisation-expiry or capture-failure risk. Cost extraction after the gate remains possible: an upheld dispute moves a delivered task to credited_or_refunded, recording a refund or credit obligation, while the contributor cost and the disclosed artefact are unrecoverable. Monotonic spent(M) bounds repetition within one mandate but not across mandates, so dispute adjudication, evidence retention, and client reputation controls remain deployment concerns. Settlement unavailability likewise triggers no modelled fulfilment effects.
Audit integrity.: Delivery without a receipt is unreachable, since the only in-edge to delivered is guarded by the construction of Omega; receipt uniqueness requires one immutable Omega per task, and verification cross-checks operator-controlled records rather than trusting a single log entry. These guarantees hold to the extent that the ledger is append-only and the receipt store durable, that the artefact hash is collision-resistant, and that the nonce store preserves its integrity. Compensations write a compensating receipt against rho_pay, making attempted refund or credit handling auditable; a separate settlement result establishes whether the refund or credit succeeded; the settlement mode as executed is recorded, including test and mock modes, so receipts remain accurate under settlement flexibility.
Post-gate client input.: The clarification channel accepts client input inside Phi. Scope, eligibility, and escalation predicates are evaluated at or before the gate and never inside Phi, so a deployment re-applies scope and eligibility policy to clarification content, or treats a clarification that changes the work as requiring a new quote under C1.
Contributors.: Contributors write to L and read task data from inside Phi. They sit outside the four payment-gating properties; deployments need contributor authentication, least-privilege access to task data, validation of contributed inputs and artefacts, and protection of the ledger and receipt stores from the fulfilment path ().
Privacy.: Omega and L are sensitive because they can identify principals, delegated authority, and contributors. The "Payment" scheme also classifies payment receipts as sensitive . The full Omega remains as defined in Section 4.4; any redacted or commitment-bearing object shared externally is a derivative with a different verification procedure. Deployments need documented retention, access-control, and disclosure policies for these records.
Cache leakage.: Payment challenges and receipts carry payer-specific, time-sensitive data; the wire scheme requires 402 responses to include "Cache-Control: no-store" and responses carrying a "Payment-Receipt" header to include "Cache-Control: private" (), and the model assumes receipts are not cached in shared caches.
Trust boundary.: As stated in , the four properties defend against a misbehaving client side. They are not guarantees against the operator, who runs all of the stores; gate-before-fulfilment is a self-enforced operator invariant, and the only externally checkable output is the receipt Omega, subject to the integrity and availability of operator-controlled records. Parties that require guarantees against the operator itself need mechanisms outside this model, such as third-party attestation of the stores.
Fail-closed discipline.: Failure of any conjunct of validate(R, S, M) causes access to be refused, with no modelled fulfilment side effect.

IANA Considerations This document has no IANA actions.