Forced Tender

x402 is an open specification for presenting and satisfying payment requirements over HTTP, and it is easiest to misunderstand when its layers are allowed to collapse into one another. By itself it is not a facilitator service, a blockchain, a stablecoin, a sequencer, an issuer, or a regulatory status. Its central design choice is nevertheless institutional: a resource server may verify and settle a signed payment locally, self-host the relevant machinery, or delegate those tasks to a facilitator. Standardization reaches the authorization message and stops there, which leaves operation allocable across those three arrangements.

This article examines that allocation through x402 source and documentation, the limited Cantina contract audit, operator pricing and terms, Base’s settlement path, the GENIUS Act rulemaking record, and Lightning Labs' Aperture implementation of L402. Gas and RPC access, transaction submission, confirmation policy, replay protection, screening, service continuity, and the legal character of the asset received remain outside the HTTP authorization message. Current x402 documentation distinguishes a public testnet quickstart from managed, self-hosted, and in-process production routes and lists a visibly plural provider field.

Residual payment operation is therefore a hypothesis, not a diagnosis. If production activity concentrates after stablecoin rules become operational, and that concentration tracks the interface carrying screening and institutional responsibility after price, documentation, chain, and service quality are controlled, the mechanism gains support. If comparable providers remain plural, switching is routine, or usage follows subsidies and canonical documentation instead, the mechanism fails. The current record shows that openness can relocate payment work; it does not show that the work has settled into a concentrated market.

Keywords: x402, machine payments, facilitators, stablecoins, settlement finality, standards, compliance, L402, PFMI.

The object is a branch in a request trace.

A client requests a protected resource. The server responds with HTTP 402 Payment Required and machine-readable payment requirements. The client constructs a payment payload and signs the authorization appropriate to the selected scheme and network. The server then decides how to verify and execute it. It may do that work locally, call a managed facilitator’s /verify and /settle endpoints, run its own facilitator, or self-facilitate inside the application. Only after the chosen settlement path returns does the server release the resource (x402 Foundation 2026a).

That trace is narrower than a payment system and wider than a message format. It standardizes an encounter between software and a priced resource, while deliberately permitting several operational arrangements below it. The title Forced Tender is a provocation, not a legal category. A server can condition access on payment; HTTP cannot make an asset legal tender, determine when the buyer’s obligation is discharged, or decide which institution must serve the transaction.

Five surfaces must therefore remain separate.

The distinction prevents three common category errors. An open specification does not imply a decentralized service market. A hosted service does not make the protocol closed. A chain confirmation does not, without the governing legal arrangement, establish settlement finality in the sense used by payment law or the Principles for Financial Market Infrastructures. Each distinction fixes what the evidence assembled below is capable of proving.

The method reconstructs a payment function from the signed request outward. For each function it asks four questions: what must be done; which component can do it; which legal person publicly offers to do it; and what evidence would show that users depend on that person. This is closer to the institutional method in payments scholarship than to a protocol feature comparison. Payment arrangements allocate information, timing, credit, and operational burdens, and those allocations can matter as much as the interface through which an instruction begins (Kahn and Roberds 2009; Awrey 2022).

The descriptive claim is modest. x402 makes authorization interoperable while leaving material production work outside the authorization message. That work includes transaction validation, replay and duplicate protection, gas and RPC provision, submission, confirmation policy, observability, incident response, screening, merchant access policy, and the choice of chain and asset.

The causal claim is narrower still. Residual payment operation names the possibility that these remaining functions become a site of dependence even when authorization is open. It does not make a facilitator a settlement institution or x402 a financial market infrastructure. The claim must be earned by evidence of costly non-substitutability: concentration, switching friction, common failure, regulatory dependence, or control over a necessary interface.

The present evidence establishes the descriptive architecture and leaves the market result unresolved. A June 16 documentation change clarified the mainnet-facilitator setup. A July 10 change stated expressly that the public x402.org facilitator should not be assumed to be the default production path for mainnet EVM routes. The documentation offers managed providers, self-hosting, and self-facilitation, while its selected directory lists eleven production options (x402 Foundation 2026b). The directory establishes plurality among listed offers; production distribution requires usage data.

Two hypotheses now organize the inquiry.

H0: documentation and standards economics. A young sponsor-originated standard clusters around reference code, canonical quickstarts, directory placement, subsidies, and bundled developer tools. Any observed concentration follows discoverability, compatibility, or price. These are ordinary forces in standards adoption and installed-base formation, not evidence that regulatory burdens have become non-modular (Katz and Shapiro 1985; Farrell and Saloner 1986).

H1: compliance-capacity residual payment operation. Once the relevant legal regime is operational, production use concentrates toward the operator or adjacent interface carrying screening, issuer access, contractual responsibility, and service continuity. That relationship persists after network, asset, price, documentation position, subsidy, and service grade are controlled. Because the reviewed GENIUS materials principally address issuers, facilitator-layer support also requires a clear pathway by which an issuer duty changes facilitator work or merchant choice. Issuer concentration alone does not count.

H0 carries real explanatory weight. It predicts the same visible fact that first motivated this paper: a sponsor-branded path can be prominent in an open standard’s early life. The hypotheses diverge only when use can be measured across time and the competing causes can be separated. Until that measurement exists, the choice between them stays open and the uncertainty stays structured.

The available evidence supports architecture, public offers, stated terms, published confirmation stages, and the legal status of proposed rules. Production settlement shares, merchant-segment denominators, normalized uptime, rejection rates, switching events, failover performance, facilitator liquidity operations, and the legal identity behind separately branded services remain unknown.

At the protocol level, the authorization/execution split is real. The x402 README describes an open and network-agnostic standard. It also says that ease of use comes from abstracting gas and RPC concerns away from the client and resource server and into a facilitator. In the reference flow, the resource server may verify a payload locally or ask a facilitator to do so; it may interact with the chain directly or post the payload to /settle; and a facilitator, if used, submits the transaction and waits for confirmation (x402 Foundation 2026a).

The facilitator documentation is equally explicit about optionality. It calls the service optional but recommended and offers three production shapes: purchase a managed service, run a facilitator, or self-facilitate in process. Each shape still has an operator, so optionality moves the role without eliminating it. The protocol does not prescribe whether that operator is the merchant, an infrastructure vendor, or a separate internal service.

Two meanings of open are too often merged. A protocol is open when parties can implement and use its specification without obtaining a proprietary network’s permission. A service market is plural when multiple providers are actually substitutable at the required price, reliability, policy, and scale. The first can be inspected in code and documentation. The second requires production evidence.

The code also shows why the remaining work is substantive. EVM schemes can let a facilitator sponsor gas while the client retains control through a signed authorization. Verification must check the scheme, network, signature, amount, destination, validity interval, and replay conditions. Settlement must construct and submit a chain transaction, handle failure, and decide what confirmation is enough before returning success. On Solana, the documentation warns of a duplicate-submission race and requires equivalent duplicate detection when a merchant settles directly. Self-facilitation replaces a vendor dependency with those internal operating burdens.

The public architecture therefore supports a functional proposition:

The security evidence is much narrower than the architecture. Cantina reviewed three Permit2 proxy contracts over February 11–13, 2026: the Base, Exact, and Upto Permit2 proxies. Its February 19 report records no Critical, High, or Medium findings, three Low findings, and four Informational findings, all marked fixed. The report is useful evidence about those contracts at the reviewed version (Cantina 2026).

Its scope stops at those three contracts and does not reach the current repository, every network implementation, facilitator operations, or the institutional claims in this article. Current HEAD contains code and functionality outside that listed scope. Audited protocol would therefore be an inaccurate compression. Three historical contracts were reviewed; the report’s severity table and fixes say what they say; everything else requires its own evidence.

That limit reinforces the paper’s method. Contract minimalism can constrain what a settlement call may do without deciding who operates the call, which transactions an operator will accept, how the service fails, or when a merchant treats the payment as complete. Technical narrowness and institutional plurality are compatible. So are technical narrowness and service dependence. The code establishes the space in which either market structure can form.

As of the source date, the public provider field is visibly plural and empirically thin. Three official operator surfaces illustrate the distinction.

These are offer terms, not market outcomes (Coinbase Developer Documentation 2026a, 2026b; PayAI 2026a, 2026b; Polygon Labs 2026a, 2026b). Even the prices resist casual comparison. A per-settlement fee may or may not include gas, may be subsidized, may apply only above a free tier, and may sit beside minimum payment amounts or separate chain charges. CDP’s reviewed pages did not make the gas treatment sufficiently consistent to normalize against PayAI’s express inclusion claim. Comparison must preserve that ambiguity rather than choose the favorable sentence.

The same discipline applies to sanctions. CDP expressly advertises transaction screening. That is evidence that one managed operator has made compliance capacity part of its product. It is not evidence that other operators do no screening, that all merchants require the same checks, or that the facilitator is the only possible location for them. A wallet can screen before signing. An issuer can apply address controls and redemption policy. A merchant can restrict customers or resources. A facilitator can reject payloads. A sequencer can impose access policy on its own service. These controls can overlap, conflict, or be purchased from a common analytics vendor.

Compliance is therefore modular in two different senses. The rule set can be split across legal actors, and the technical checks can be supplied through APIs even when responsibility remains elsewhere. Concentration is one possible result: a regulated merchant may prefer an operator that bundles screening, records, support, and a familiar contract. Dispersion is another: specialized compliance services may make those capabilities cheap enough for independent facilitators and self-hosted merchants. Migration is a third: the decisive control may settle at the stablecoin issuer or wallet rather than the facilitator. Architecture alone cannot select among these three outcomes, and the selection requires production evidence.

The liquidity claim is weaker. A facilitator that sponsors gas needs native tokens and operational treasury controls. That does not establish a material stablecoin inventory, prefunding obligation, intraday funding exposure, conversion bottleneck, or privileged access to redemption. The reviewed public record contains no operator balance sheet, funding schedule, stress event, or measured liquidity-induced outage. Chain and asset support can create complementarity; it is not proof of a liquidity barrier. Liquidity remains a variable for later study, not a demonstrated cause of facilitator concentration.

Branding supplies another temptation. CDP, Base, and other Coinbase-branded interfaces can appear as a continuous stack to a developer. Their legal documents do not permit the article to call them one person. Base’s terms identify Coinbase Technologies, Inc. for the covered sequencer service. CDP’s developer-platform terms may identify Coinbase, Inc., Coinbase Crypto Services LLC, or an affiliate depending on the service (Base Documentation 2026a; Coinbase 2026). Common branding can reduce search and integration costs without merging corporate responsibility. The article can study the bundle as a user experience only if it preserves the entities underneath it.

The exact result is more specific than concentration: the offer layer is plural; the usage layer is undisclosed. Without production counts and values, merchant segmentation, comparable terms, and substitution evidence, dominance is not measurable.

The word settle does too much work in this field. In x402, /settle names an operation through which a facilitator submits an authorized transfer and returns an execution response. In a blockchain explorer, confirmed describes the transaction’s place in a chain’s evolving state. In payment law and the PFMI, final settlement concerns irrevocable and unconditional transfer or discharge under the relevant arrangement. In stablecoin economics, redemption concerns conversion of the token claim into the referenced monetary value. These events can occur at different times.

Base makes the separation visible. Its current documentation publishes four stages for ordinary L2 transactions: approximately 200 milliseconds for a Flashblock preconfirmation, two seconds for inclusion in an L2 block, two minutes for inclusion in an Ethereum L1 batch, and twenty minutes for L1 batch finality. The seven-day fault-proof period applies to withdrawals from Base to Ethereum, not to ordinary L2 transfers (Base Documentation 2026b).

Those stages are engineering confidence levels, not four competing definitions of legal discharge. Base itself describes decreasing reorganization probability as the transaction moves through them. A merchant might release a low-value API response after the first or second stage; a different merchant might wait for L1 inclusion. That is a product and risk decision. Whether the underlying debt is discharged at the same moment depends on the merchant agreement, the governing law, the asset promised, and any rule specifying the accepted confirmation state.

The Base node pin clarifies the operational path. Running a node requires Ethereum L1 execution and beacon endpoints. Its mainnet configuration points to a Base sequencer endpoint. Base’s April 8 terms state that the Coinbase Sequencer is initially the only sequencer, acknowledge other submission mechanisms through Ethereum, reserve discretion to prohibit wallet addresses from using the sequencer, and reserve the right to charge or modify fees (Base 2026; Base Documentation 2026a). The sequencer is therefore a material service on this route. It is not the x402 protocol, the facilitator, or the stablecoin issuer.

The asset must also be named accurately. If the merchant receives USDC on Base, the immediate settlement asset is the USDC balance on that ledger. It is a privately issued payment-stablecoin liability with redemption and reserve arrangements around it. It is not commercial bank money in the PFMI sense merely because reserve assets can include bank deposits. The PFMI define commercial bank money as a commercial-bank deposit liability used for settlement on the bank’s books. CPMI-IOSCO’s later stablecoin guidance recognizes that a stablecoin settlement asset may be neither central bank nor commercial bank money and asks what participants hold when the payment obligation is extinguished (CPSS-IOSCO 2012; CPMI-IOSCO 2022).

This produces a four-step institutional chain without claiming that every transaction uses the same legal arrangement:

PFMI Principle 8 is useful here because it refuses to reduce finality to interface success. It defines final settlement through irrevocable and unconditional transfer or discharge and requires a clear legal basis. CPMI-IOSCO’s stablecoin guidance goes further: distributed-ledger state can become misaligned with legal finality, so a systemically important arrangement should define the point of irrevocability and maintain legal finality despite competing ledger states (CPMI-IOSCO 2022).

That guidance does not transform Base or x402 into an FMI. It identifies the question the engineering vocabulary leaves open. A facilitator’s successful response, a sequencer preconfirmation, L1 finality, and stablecoin redemption are distinct artifacts. A credible institutional account must say which one it is discussing every time it uses settlement.

The United States now has a payment-stablecoin statute but, as of July 15, 2026, no completed implementing perimeter. Public Law 119-27, the GENIUS Act, was enacted July 18, 2025. Section 13 directs the relevant regulators to promulgate implementing regulations within one year. Section 20 makes the Act effective on the earlier of January 18, 2027 or 120 days after the primary federal regulators issue any final implementing regulations (United States Congress 2025).

The major reviewed federal materials remained proposals. The OCC’s foundational proposal opened in March. A joint customer-identification proposal opened June 22 with comments due August 21. The OCC’s permitted-issuer AML/CFT and sanctions proposal opened June 24 with comments due July 24. The FDIC had its own foundational and related permitted-issuer proposals. No final implementing regulation was located in the official source set as of July 15 (Office of the Comptroller of the Currency 2026a, 2026b, 2026c; Federal Deposit Insurance Corporation 2026).

Two consequences follow. First, the post-rule observation period proposed in this paper has not begun. A proposal can alter expectations, product design, and legal budgets; it cannot serve as the effective rule date in a falsification test. Second, the principal addressees in the reviewed AML/CFT and sanctions proposals are permitted payment stablecoin issuers. The materials do not say that every x402 facilitator is a directly regulated issuer or that the facilitator must carry the full issuer program.

The statute itself resists a code-equals-business shortcut. Its definition of digital asset service provider excludes, among other things, a distributed-ledger protocol, development or operation of self-custodial software interfaces, validating transactions or operating a ledger, and participation in a peer-to-peer liquidity pool. Those exclusions do not immunize every commercial service assembled with open code. They do require analysis of the activity and actor rather than regulation by repository association.

The likely compliance architecture consequently stays open. An issuer will carry issuer obligations. A merchant may carry sanctions, consumer, tax, or sector-specific duties independent of x402. A managed facilitator can sell screening and records as a service. A wallet can block or warn. A chain service can enforce its terms. The same transaction may encounter several controls, none of which is dictated by the HTTP authorization specification.

This is where the original concentration intuition must face its strongest objection. Regulation can create fixed costs and favor large bundled providers. It can also create standardized interfaces, specialist vendors, contractual delegation, and shared utilities that let smaller operators compete. The GENIUS perimeter may concentrate the stablecoin issuer layer while leaving facilitation plural; it may push screening to facilitators; or merchants may internalize the function. The article has no warrant to decide in advance.

The European payment-initiation model supplies a disciplined contrast. PSD2’s Payment Initiation Service Provider opens an initiation role inside a specified institutional perimeter: authorization, access, authentication, liability, and supervision are not left to an HTTP convention alone (European Parliament and Council 2015). x402 does not create an equivalent licence. But an x402 operator can separately be regulated, contracted, or integrated with regulated actors. The contrast is between architectures of responsibility, not between regulated PSD2 and unregulated x402 as total systems.

The regulatory proposition is therefore conditional. If legal duties become difficult to modularize, production merchants may prefer a bundled operator. If duties are supplied through interoperable issuer, wallet, or screening interfaces, facilitator plurality may survive. The first outcome supports residual payment operation at the facilitator or adjacent compliance interface. The second confines the concept to a map of functions.

L402 is the closest technical comparator because it starts from the same HTTP status and reaches payment through a different substrate. The comparison should be made from a running implementation rather than a protocol slogan.

Lightning Labs' Aperture is a reverse proxy used by Lightning Loop. It issues an HTTP authentication challenge containing a macaroon and Lightning invoice. Payment reveals a preimage; the preimage becomes part of the L402 credential; the proxy verifies the token and the invoice state before granting access. The operator configures the service, price, authentication scheme, timeouts, storage, Lightning backend, blocklists, and optional rate limits. The code has a one-satoshi default service price but permits explicit or dynamic pricing (Lightning Labs 2026).

That path carries no x402-style external /settle facilitator and no protocol-defined stablecoin issuer. Aperture instead places the operational center in the service operator’s proxy, macaroon mint, Lightning node connection, invoice database, channel and route liquidity, and policy configuration. Facilitator is not the same role in L402, so its market structure and compliance allocation require different evidence.

The comparator narrows the claimed novelty. Open HTTP payment initiation has prior art, and so does separating a credential from an underlying payment. The potentially distinctive proposition concerns the remainder: a stablecoin-and-chain implementation can make the remaining institutional interfaces unusually modular and visible, so that facilitator, issuer, wallet, sequencer, RPC, and merchant can be varied independently in the specification even when production bundles them.

PFMI Principle 19 and Annex F help state what would matter if those interfaces became systemically or operationally important, but their terms must not be appropriated. Principle 19 concerns risks to an FMI when indirect participants rely on direct participants bound by the FMI’s rules. The x402 repository does not establish an FMI, a common participant rulebook, or the direct/indirect relationships the Principle presupposes. It would be inaccurate to call merchants indirect participants and facilitators direct participants simply because one relies on the other (CPSS-IOSCO 2012).

Annex F similarly sets oversight expectations for critical service providers to FMIs. It assumes an FMI that remains responsible for outsourced operations and an authority capable of obtaining assurance. An x402 facilitator is not automatically a PFMI critical service provider. The analogy is diagnostic only: if many merchants rely on one operator, the variables Annex F emphasizes, including risk management, information security, reliability, technology planning, communications, contractual information rights, and substitutability, become sensible objects of inquiry.

Principle 19 also exposes what a serious concentration study would measure: the volume and value routed through an intermediary, dependencies large relative to that intermediary’s capacity, and the system effect of its disruption. Those data are absent here. PFMI does not close the gap; it makes the gap legible.

This is the conceptual limit of residual payment operation. If the term merely renames everything outside an authorization message, it adds little to payments scholarship. It becomes useful only if it identifies a patterned relocation of control and predicts where measurable dependence will form. That is why the null hypothesis, the observation clock, and the falsifiers are part of the concept rather than an appendix to it.

Every result reported here is bounded to public sources as they stood on July 15, 2026. Within that boundary the article reports protocol architecture, published offers, stated contractual terms, published confirmation stages, and the legal status of proposed federal rules. Production settlement counts and values, merchant-segment denominators, normalized uptime, rejection rates, switching events, failover performance, facilitator liquidity operations, and the legal identity behind separately branded services fall outside it, and no inference in the article depends on them.

Each source layer carries its own limit. Cantina reviewed three Permit2 proxy contracts at the reviewed version, so the report speaks to those contracts and leaves current HEAD, other network implementations, and facilitator operations untested. Operator pages publish offers where they publish anything; a published offer states a price or a policy commitment, and use has to be measured separately. Base’s four stages describe engineering confidence on one L2 route, and the moment at which a buyer’s obligation is discharged still depends on the merchant agreement and the governing law.

Timing bounds the causal claim more tightly than any single source does. The observation period proposed in this article runs from a final implementing regulation, none had been located in the official source set, and no post-rule measurement is reported or implied. Aperture supplies the L402 comparison as the lightninglabs/aperture repository publishes it, which shows what an operator configures rather than how any operator has configured it, and settles nothing about L402 market structure at large. PFMI Principle 19 and Annex F enter as diagnostic vocabulary: the x402 repository establishes no FMI, no participant rulebook, and none of the direct and indirect relationships those provisions presuppose.

The affirmative claim here is architectural: x402 fixes an interoperable authorization message and leaves verification, execution, gas and RPC provision, confirmation policy, screening, continuity, and the legal character of the received asset to an arrangement the specification does not prescribe, with an operator field that publishes plural offers while production use stays undisclosed. Five observations would defeat that claim or a statement it rests on, and each is checkable against a public record.

Each condition names a retrievable artifact: a specification file, a corporate terms page, a provider disclosure, a contract term, or a published rule. None of them requires a forecast about future concentration, which keeps the refutation test separate from the measurement programme set out below.

A concentration claim requires production share by merchant segment, chain, asset, and scheme; comparable measures of price, gas, uptime, rejection policy, support, and subsidy; and evidence of switching, multi-homing, or failover. It also requires identifying which legal actor performs screening, record-keeping, onboarding, and reporting for each route.

Concentration would support residual payment operation only if it persists around the interface carrying costly compliance and service obligations after documentation, compatibility, price, and subsidy are considered. Comparable providers serving the same merchants, low-cost switching, or use that follows quickstarts rather than compliance capacity would weaken the mechanism.

The allocation of work is already visible. x402 makes facilitation optional while leaving verification, execution, gas, RPC, confirmation, screening, continuity, and the legal meaning of payment to the surrounding arrangement. Managed operators can bundle those functions; merchants can internalize some of them; issuers, wallets, and chain services can carry others. The provider field is plural at the level of offers and opaque at the level of use.