Forced Tender

Replacing a payment operator involves two distinct capabilities: handling future requests and preserving claims already accrued. x402’s EVM batch binding makes the second capability concrete. Outstanding vouchers, receiver authorization and timely claim inclusion affect whether a merchant can recover its payment position after an operator change. The binding permits direct claims by the receiver, followed by permissionless transfer of claimed funds to that receiver.

A source-to-deployment comparison and isolated execution identify specific claim, withdrawal and transfer conditions in the inspected contract. The analysis places those conditions alongside operator offers, ledger confidence, legal discharge and competing explanations for provider choice. Published studies supply historical activity and concentration measurements; merchant dependence and its proposed regulatory cause require further evidence.

A client requests a priced resource. The server returns HTTP 402 Payment Required with machine-readable payment requirements. The client supplies a payment payload appropriate to the selected scheme and network. Someone must then validate that payload, maintain the state on which validation depends and carry out the scheme’s settlement process. x402 standardizes interfaces and requirements for those acts while permitting several organizational arrangements (x402 Foundation 2026).

A merchant using a managed facilitator delegates work through /verify and /settle. Another merchant can run its own service or self-facilitate within its application. A public testnet quickstart does not identify the production provider that either merchant must use. The reviewed README expressly separates those choices and warns against assuming that the public x402.org facilitator is the default mainnet-EVM path.

Payment timing also depends on the scheme. In the documented immediate-transfer flow, verification precedes execution and a successful settlement response carries an on-chain transaction result. Under batch-settlement, a valid commitment can authorize access while value moves later through the network binding’s redemption process. Its successful response identifies a commitment. Treating both responses as proof of an immediate completed transfer would erase the scheme’s central distinction.

A replacement might handle the next payment request while lacking earlier vouchers, the authority to claim them or the time needed before withdrawal. The comparison therefore follows the merchant’s existing payment position through a relay change, an authorization change, channel migration or recovery. The EVM binding supplies concrete constraints and alternative routes for each assessment.

The general batch-settlement scheme requires each network binding to define commitment format, verification, storage, double-spend prevention, expiry, redemption and trust model. It permits capital-backed and credit-backed commitments. The EVM binding uses client-funded escrow and cumulative vouchers. Other bindings can allocate backing differently. The existence of a capital or credit requirement does not make the facilitator its supplier (x402 Foundation 2026, batch-settlement specifications).

The EVM binding makes authorization and transaction submission separable. The server chooses a receiverAuthorizer: its own address, a server-controlled smart contract, or a facilitator-provided address. Anyone can relay a valid authorization signature. The binding also permits direct claims by the receiver or receiver authorizer, while the later transfer of claimed funds to the receiver is permissionless. A delegated facilitator therefore need not be the sole actor able to recover value. These are specified routes whose actual availability depends on the receiver and authorizer implementation.

Changing an authorization arrangement can nevertheless differ from changing a relay. The channel identifier incorporates an immutable configuration, including the receiver-authorizer address. A parameter change requires a new channel. The binding recommends claiming outstanding vouchers and refunding old-channel balances before switching a delegated facilitator; it also permits a server-controlled contract authorizer, including for key rotation. The relevant comparison therefore follows the route available in a particular design, the outstanding claims and the work needed to complete or transfer them (x402 Foundation 2026, EVM binding, “Authorizer roles,” “Channel reuse and parameter changes,” and “Claim & Settlement Strategy”).

Continuity also depends on what a caller can recover after an uncertain transaction. The facilitator guide specifies that when confirmation of a broadcast transaction is uncertain, settlement_pending includes its hash and network so the caller can reconcile on chain before retrying. Automatic retry uses a pending store whose in-memory default requires the same process; a multi-instance deployment can provide shared storage. When the caller receives those identifiers, on-chain reconciliation remains available across a process change. A platform deadline can kill the process before it returns a hash, leaving the caller with a 5xx. Testing a deployment must distinguish those outcomes (x402 Foundation 2026, facilitator guide, “Settlement pending and auto-recovery”).

Recovering a service also differs from preserving its economic position. Under the EVM batch binding, the server recovers its operating baseline from on-chain totalClaimed; lost unclaimed charges are forfeited. Restarting the service can therefore preserve future operation while failing to preserve the prior economic position. For substitution, the relevant objects are custody of outstanding vouchers, retained authorization and the ability to reconcile an existing transaction (x402 Foundation 2026, EVM binding, “Recovery After State Loss”).

Timely claim inclusion supplies another continuity condition. In the reviewed EVM contract, only cumulative claims already recorded on chain reduce the amount available for the payer’s timed withdrawal; a signed voucher awaiting submission does not reserve escrow. Local execution confirms that an outstanding claim can fail for insufficient escrow after the payer withdraws. A claim included during the withdrawal window preserves its amount and limits the final withdrawal. A later redeposit to the same channel can restore the capacity to claim the earlier voucher. The receiver can submit that claim directly, and anyone can subsequently settle the recorded amount to the receiver. Preserving and submitting accrued claims in time need not bind the merchant to one relay. The local scenarios establish the inspected contract’s ordering conditions; no merchant loss is observed (x402 Foundation 2026, EVM contract, claim and withdrawal functions).

The inspected EVM batch contract was observed on Base at block 52,772,710, address 0x4020074e9dF2ce1deE5A9C1b5c3f541D02a10003. Fresh compilation reproduces its complete runtime after reconstructing the seven compiler-declared EIP712 values: name and version hashes, their short-string representations, chain ID, verifying address and cached domain separator. The comparison identifies the executable rules used in the local tests; it does not reconstruct the deployment-creation transaction. The Base and BlastAPI code responses agree with the retained Sourcify runtime (Sourcify 2026).

Security can separately constrain execution within one payment. Cantina’s February report reviews three Permit2 proxy contracts at c0a80b76, rather than the whole current repository. It records a fix that binds an intended facilitator into the witness to address settlement interference, while noting a centralization risk. A constraint on that signed payment does not establish inability to select another provider for later payments (Cantina 2026, 3–4).

Operator pages now disclose materially different pricing structures. In the October capture, CDP states a monthly free tier followed by a fee per on-chain transaction and advertises screening. PayAI describes cost-plus pricing introduced on 21 September, with a lifetime free-credit allowance for new receiving wallets (Coinbase Developer Documentation n.d.; PayAI n.d.; Polygon Documentation n.d.).

Published transaction studies supply historical evidence of facilitator use alongside these offers. Wang and colleagues (2026, sec. 7) report historical facilitator-level concentration from Base and Solana transaction measurement. Their inclusion relies on registered facilitator addresses and settlement filters; they acknowledge incomplete discoverability and imperfect attribution. Their activity plots cover October to December 2025.

Ling and colleagues (2026a, sec. 3) examine a 280-day window from 17 September 2025 through 23 June 2026. They resolve payers through the meta-transaction layer and distinguish what payment graphs can establish about fictitious, internal and unattributed activity. Their Solana count has coarser attribution than the Base analysis. The study separates gross settlement counts from evidence of independent commercial adoption. Its results also depend on stated event definitions and facilitator lists.

The studies provide historical baselines for facilitator activity and concentration. Their samples, methods and denominators differ, so their totals cannot be pooled into one market series. Neither study identifies a compliance-cost effect on merchant selection, measures all merchants' outside options or shows that the same contracting person controls every similarly branded component. Any causal extension must establish those additional links.

Implementation security supplies another possible explanation for provider choice. Ling and colleagues' (2026b) analysis examines authorization and state-synchronization failures across layers. A merchant may prefer an operator that maintains correctness or absorbs an operating burden. The historical analysis does not establish which reported vulnerabilities remain exploitable.

A successful application response, a ledger confirmation and discharge of a payment obligation can occur at different points. The relevant sequence is particularly visible on a Base route, but x402 does not require Base and the sequence cannot be projected onto every supported network.

The captured Base documentation describes approximately 200 milliseconds to Flashblock preconfirmation, two seconds to L2 block inclusion, two minutes to L1 batch inclusion and twenty minutes to L1 batch finality. Those are the provider’s engineering stages and approximate timings. Its separate withdrawal-finalization window is five days for a single-proof dispute game or one day on the dual-proof path when both TEE and ZK proofs support the same proposal. The page also identifies proposal and transaction steps that add to end-to-end withdrawal time. These withdrawal routes concern movement to Ethereum (Base Documentation n.d.-a).

The documented Base service terms identify Coinbase Technologies, Inc. and reserve powers concerning the covered sequencer service. The CDP terms define their Coinbase party through the entity or affiliate supplying the tools. Common branding consequently requires a service-specific legal analysis. It does not demonstrate that one person supplies facilitation, sequencing, stablecoin issuance and fiat access (Base Documentation n.d.-b; Coinbase 2026).

PFMI Principle 8 describes final settlement through irrevocable and unconditional transfer or discharge under an applicable legal arrangement. The later stablecoin guidance also distinguishes ledger state from legal finality. What the receiving participant holds when its payment obligation is extinguished matters to that analysis (CPSS-IOSCO 2012; CPMI-IOSCO 2022). A stablecoin does not become a commercial-bank deposit liability merely because its reserves include bank deposits.

For a merchant, at least four questions follow: what payment was authorized; what the operator submitted or accepted as a commitment; what confidence the relevant ledger state supplies; and whether receipt of that asset performs the buyer’s obligation. A batch commitment may add a period of exposure before redemption. The commercial agreement and applicable law determine whether token receipt is sufficient performance or whether another step is required.

PFMI Principle 19 concerns indirect participation in an FMI under a rule-bound direct-participant arrangement. Annex F concerns critical service providers to FMIs, with responsibilities and oversight that the x402 repository alone does not establish. They make volume and value dependence, substitutability, information rights and continuity relevant objects of study. They do not make every facilitator a direct participant or a PFMI critical service provider.

The GENIUS Act’s issuer framework must be distinguished from the business of facilitating an HTTP payment. Its definitions exclude specified protocol and software activities from the digital-asset-service-provider category, while commercial activities assembled with that software still require their own analysis. The statute’s issuer requirements do not make every facilitator an issuer (United States Congress 2025, secs. 2, 4).

Treasury’s interim final rule on state-certification review procedures became effective on 30 September 2026. It sets forms and procedures for the Stablecoin Certification Review Committee and says certifications will not be accepted until information-collection approval (United States Department of the Treasury 2026).

The reviewed OCC and FDIC material separately describes issuer proposals, and the FinCEN/OFAC proposal addresses permitted payment stablecoin issuers (Office of the Comptroller of the Currency 2026; Federal Deposit Insurance Corporation 2026; Financial Crimes Enforcement Network and Office of Foreign Assets Control 2026). Publication, effectiveness, phased applicability and the actor subject to a duty require separate treatment. Section 20 supplies the Act’s effective-date rule; the published September procedural text expects the Act to take effect on 18 January 2027.

A test of compliance-induced dependence needs a more specific event. It must identify a binding obligation affecting an identified actor, when that obligation applies, how it changes an operator’s work or a merchant’s choice, and an appropriate comparison. Issuer duties could affect facilitator contracts or access indirectly, but that transmission must be demonstrated. A procedural milestone and a price change in the same period cannot establish the connection.

Regulation can also support modular services. Issuer controls, wallet policy, merchant checks, screening vendors and managed facilitators can divide the work. Standardized interfaces and specialist suppliers may let smaller operators compete, while fixed costs or non-transferable contracts may favor a bundle.

L402 supplies a technical comparison because an HTTP challenge reaches payment through another substrate. At the pinned October Aperture source, a reverse proxy combines a macaroon with a Lightning invoice and verifies the resulting credential and payment state. Service configuration allocates pricing, storage, backend access and policy to its operator. This is a source reconstruction, without an independent production-use study (Lightning Labs 2026).

Aperture does not require x402’s stablecoin-and-facilitator arrangement. It still needs operational continuity, invoice and credential state, and access to a Lightning backend. Removing a role from a protocol diagram can relocate a burden to a merchant or another supplier. The comparison should therefore follow the function and the actor carrying it, rather than count the named intermediaries.

Regulated payment initiation supplies a different contrast. PSD2 allocates authorization, access, authentication, liability and supervision to specified institutions and services. The x402 standard itself creates no equivalent licence, though a particular operator can separately occupy a regulated role (European Parliament and Council 2015, arts. 5, 22, 64, 66, 73, 97, 100). The useful comparison concerns the allocation of responsibility and recourse, not a binary ranking of regulated and unregulated technology.

Payment unbundling already has an institutional account. Awrey (2022, 722–724) proposes access to central-bank accounts alongside conditions on the business that can obtain access. His analysis makes dependence on an incumbent an issue of access and legal architecture, rather than simply the presence of an intermediary. Opening a software interface is a different intervention. It can leave access to backing, records or contractual performance unchanged.

Compatibility research also makes retained use an ambiguous observation. Farrell and Saloner’s revised working paper (1986, introductory discussion, manuscript pp. 1–5) examines adoption when users have an installed base and a new network takes time to grow. Its model concerns transition between incompatible technologies. Merchants selecting between implementations of one open scheme might instead retain their existing complement set. Transposing the model therefore requires evidence about the incompatibility or foregone network benefit. Kahn and Roberds (2009) and Katz and Shapiro (1985) provide broader payment and compatibility background.

The strongest rival explanation is efficient delegation: merchants select a reliable specialist because its service is cheaper or better than internal provision. A provider can earn most transactions while merchants retain effective outside options. To distinguish that outcome from dependence, the analysis must identify the incumbent-controlled property, a feasible alternative and the cost or position lost in moving. Documentation position, subsidies, security, chain compatibility and service quality can all produce clustering without a non-modular legal obligation.

The compliance mechanism specified above can be tested against those alternatives. Routine switches that preserve the required position would weaken the proposed explanation, as would use that tracks a subsidy or reference integration. Concentration alone cannot adjudicate among those explanations.

The observations needed are consequently specific: a consistent transaction population and attribution method; comparable providers, networks and schemes; pricing and gas treatment; service and rejection outcomes; contracts allocating duties; and actual switching or failover. Historical measurement can supply a baseline for a prospective or retrospective comparison of a specified change.

The October source record combines the inspected specification, source files, operator offers, terms and regulatory documents with attributed historical measurements and reported implementation findings. This article performs no new transaction census or production benchmark, and it independently reproduces neither study’s measurement results.

The separate source review matches the pinned EVM batch contract to a dated Base deployment, including independently reconstructed EIP712 immutable values. Ten isolated local scenarios exercise its claim, withdrawal and settlement behavior. Fifteen standalone retry-store tests check remembered transaction hashes and their limits. These tests establish bounded source behavior; they measure neither production failure rates nor merchant substitution.

The proposed compliance mechanism remains a causal hypothesis about an identified duty and merchant substitution. The evidence needed to establish its regulatory cause remains outstanding. The assessment questions derived from the inspected routes also require testing for cost, effectiveness and suitability across other bindings.

A change of payment operator should be assessed against the economic position a merchant can recover, alongside its ability to accept fresh payments. In the inspected EVM binding, that means following the outstanding vouchers, the authority to submit a claim and the time available before withdrawal. The direct-claim routes show why this comparison can distinguish replacement of a relay from loss of a payment position.

Earlier versions treated x402 use as wholly undisclosed and GENIUS Act implementing materials as uniformly proposed. The historical transaction studies and Treasury’s effective procedural rule supersede those premises. The July version’s account of PayAI’s monthly allowance and flat pricing is also superseded by the October offer.