Two Agents Meet Once and Never Again
A procurement agent encounters a supplier agent it has never seen, on a network neither one administers. There is no shared account, no session key, no prior enrollment, no platform both already trust to adjudicate. They exchange terms and one of them pays. A week later the supplier's operator says the offer was never made on those terms, and the buyer's operator holds a log file it wrote itself.
Two different artifacts are in play here. One is the transfer of value. The other is a record of terms that was produced from both parties' own signatures, that a party present for neither side can verify, and that survives in each party's own hands. Machine-speed commerce raises the frequency of encounters between parties with no prior relationship, which is what makes the second artifact worth designing for rather than assuming.
The question here is narrow: what does it take, structurally, for two agents that have never met to produce a mutually binding conduct record, and what happens when one of them declines.
What x402 Sets Out To Do
Coinbase x402 is, as publicly described, an open payment protocol that makes HTTP the negotiation surface for machine-initiated payments. It reaches for the long-reserved HTTP 402 Payment Required status code. As publicly documented, a server responds to an unpaid request with the terms it will accept, the client constructs a payment payload and retries the request carrying it, and the server returns the resource once payment is verified. The public materials describe the design as chain-agnostic and oriented toward stablecoin settlement, and describe facilitator services as an option so that a resource server need not operate chain infrastructure of its own.
The design intent deserves to be stated in its own terms, because it is a good one. Conventional commerce assumes a human at the account-opening step: someone signs up, agrees to terms, receives a key, attaches a card. An agent that needs one call from a service it discovered moments ago is a poor fit for that sequence. What x402 does, as publicly described, is put the payment inside the request, so the interaction can complete without either side having provisioned a relationship beforehand. That addresses a real problem at the layer where it appears, which is the HTTP exchange itself.
The Matched Pair as the Settlement Primitive
The filed architecture starts from a different object. In an embodiment of U.S. Provisional Application No. 64/117,812, a bilateral exchange between a semantic agent (100) and a counterparty settles through a matched pair (600) of governed observations, each bearing an authority credential, the pair recognized within one or more of a spatial proximity window and a temporal proximity window (602).
A governed observation is a signed structure carrying, in sequence, an authority credential field, a continuity hash field encoding identity continuity of the emitting party, a spatial reference field, a temporal reference field, a time-to-live field, a payload field, and an observation lineage field. One lacking a verifiable authority credential is not a governed observation within the meaning of the disclosure. Emission is complete upon emission: the emitter requires no acknowledgment, no handshake, no delivery confirmation, and no registration with a central authority.
The first governed observation (608) represents an offer, tender, claim, demand, or commitment; the second (610) an acceptance, counter-tender, acknowledgment, refusal, or fulfillment. A pairing rule recognizes them as a pair, requiring spatial coincidence, temporal coincidence, or both as the governing policy object declares, and admits several forms, among them a content-matching form, a cryptographic-handshake form in which the first observation commits to a challenge and the second produces the response, a derivation-chain form, and composites. Where the rule is satisfied, the result is bound into a settlement record (604): the two signed observations, a cryptographic binding over both, and an attestation of the window within which the pair was recognized. That record supports non-repudiation and is verifiable by a downstream consumer from the record alone.
Three negative conditions accompany that mechanism. No third-party intermediary participates: no clearing party, no payment processor, no platform adjudicator, and no escrow party is required for the pair to settle. No centralized consensus is computed: no quorum, no distributed ledger commit, and no consensus round is a condition of settlement, and finality attaches upon recognition and admission of the pair itself. No pre-negotiated session state exists: no account relationship, no session key, no standing channel, and no prior enrollment is a precondition, consent being expressed per transaction by the paired observations.
Identity, in place of enrollment, is carried by continuity. The continuity hash field has two subfields computed by different constructions: a successor hash field, being the dynamic agent hash of the emitting party at emission, verified by an equality test and not a distance test; and a continuity vector field, an ordered tuple of a declared count of components, each a projection of the emitting party's operational state normalized to the interval from zero to one. A trust-slope validator computes a consistency measure from the continuity vector field and no other field. An observation is accepted on continuity where both conditions hold conjunctively: the per-step distance against its predecessor does not exceed a declared per-step ceiling, and the measure is not less than a declared acceptance threshold. Both are declared in the governing policy object, and the filing recites no value for either.
Refusal is a first-class move rather than a failure. A party declining to complete a pairing emits a refusal observation, itself a governed observation referencing the offer refused, which pairs with that offer and is recorded by both sides. That emission is metered against the refusing party's own settlement-binding authorization, by an increment declared in the governing policy object and accumulated over a declared window. Where the meter satisfies the declared bound, that authorization is written from a granting state to a withheld state and binds no further settlements, while its capacity to observe, to produce determinations, and to emit further refusals is preserved. The meter is applied without any determination of whether the refusal was well founded. Initiating a dispute, protracting a negotiation past its round count, a timeout, and a failed fulfillment increment no meter of either party.
Each party appends its own settlement-lineage entry (606) into an append-only lineage field (104), recording both observations, the pairing determination, the cryptographic binding, each escrow event, each failure and rollback, and each downstream consumption. A party's transaction history is reconstructible without recourse to the counterparty and without recourse to any registry. Entries are neither removed nor modified; a reversal is itself appended.
Adjacent Layers, Not Competing Ones
Start with the convergence, which is genuine. Both designs accept that a machine counterparty cannot be asked to enroll before it transacts, and both compress the interaction into a single exchange between strangers. The divergence is in the object each one produces. x402, as publicly described, produces a payment authorization scoped to an HTTP request, with settlement of value on chain. The filed architecture produces a bilateral evidentiary artifact: two signed statements of terms, held per party, with the window of recognition attested inside the record and finality attaching on recognition and admission of the pair.
The identity requirements differ in kind as well. A payment protocol needs to establish that a payer controls funds at the moment of payment. The disclosed architecture requires something else of an emitter, namely that it be shown continuous with an emitter previously seen, through the successor hash and the continuity vector, and it requires that this showing be carried in the observation itself. These are requirements on different quantities, which is why the two sit at adjacent layers rather than in the same slot.
Admission in the filed architecture is graduated rather than binary. A settlement admissibility evaluator produces exactly one outcome per governed observation, candidate pair, release request, and rollback, from admit, gate, defer, solicit, reject, and escalate. The reject outcome records a rejection-reason classification from insufficient authority, failed continuity validation, staleness, failed corroboration, and window violation. Evidential weight is the sum over four factors, authority, continuity, freshness, and corroboration, each times a declared coefficient, the coefficients being non-negative and summing to unity.
Where They Would Sit Together
Consider a deployment in which both are present. The buying agent's request meets a 402 response and retries with payment, and value moves on that rail. In the same encounter, the offer would be emitted as a first governed observation (608) and the acceptance as a second (610); where the pair falls inside the declared window and is admitted, each side writes its own settlement-lineage entry (606). Should the counterparty decline, the refusal is emitted as an observation, paired, and recorded, and the meter moves against the refusing party's own settlement-binding authorization. If the second observation never arrives, the timeout detector resolves the pairing, and a timeout resolves nothing against either party: neither the unanswered party nor the party that did not answer incurs any adverse consequence.
Content can sit under an escrow custody record whose release condition is, in an embodiment, completion of the declared matched pair (600), including a dual-lock form in which each party holds one lock. Escrow depth is bounded above by an escrow-depth bound declared in the governing policy object, and a placement that would exceed that bound is not performed.
The limits on the disclosed side are worth stating plainly. It does not move funds, and the filing recites neither a settlement asset nor a rail. Its behavior is only as good as the governing policy object a deploying authority issues, since the windows, the pairing rule form, the continuity parameters, the factor coefficients, the refusal increment and bound, the escrow-depth bound, and the retry and round bounds are all declared there, and where the parties resolve different policy objects each applies its own. Credential issuance is presupposed rather than solved: an observation without a verifiable authority credential is outside the scheme. A settled pair is challengeable only through a credentialed dispute procedure routed to a resolution procedure declared in the governing policy object, so the forum remains an institutional question that the architecture records but does not answer.
Disclosure Scope
The architecture described here is disclosed in U.S. Provisional Application No. 64/117,812, and the matched-pair subject matter originates in U.S. Provisional Application No. 64/049,409. These are pending applications; nothing here is a representation about the scope of any issued claim. Statements about the disclosed architecture describe embodiments as filed, including quantities that are declared in a governing policy object and for which the filing recites no value.
References to the x402 payment protocol are to public materials and are used for comparison only; no relationship, endorsement, or infringement is asserted.
