What You Are Building
You are building a way for two devices to complete an exchange and produce a durable, verifiable record of it, with no third party sitting in the middle. The two parties might be a toll gantry and a vehicle, a merchant terminal and a customer's agent, a hand-off between two custodians of a shipment, or two nodes transferring energy or reserved capacity. Whatever the exchange, you want three things at once: both sides genuinely consented to this transaction, the record survives for later audit or dispute, and no clearinghouse, payment processor, or consensus network had to be online to make it happen.
The specific problem a searcher usually has is the last part. It is easy to record a transaction if you are willing to call out to a central authority. The hard version is settling directly between the two devices, where "settled" means something more than "both sides sent a message." You need a record that a downstream party will accept as authentic without having to trust either transacting party's unilateral word for it.
The architecture below, disclosed in U.S. Provisional Application No. 64/049,409 as the Matched-Pair Settlement inventive step, treats this as pairing two independently signed observations inside a bounded spatial and temporal window, then binding them into a single persistent settlement record that carries its own provenance.
Why the Obvious Approaches Fall Short
There are three conventional routes, and each is a real, legitimate technology. The point is not that they are bad, but that each carries a structural cost that the direct-settlement problem is trying to avoid.
Central payment processors and clearinghouses settle through a regulated intermediary. The intermediary holds counterparty risk, reconciles the two sides, and produces the authoritative record. This works well and is the backbone of most commerce, but by construction it puts a third party in the transaction path. If your requirement is that no intermediary is involved, this route does not satisfy it.
Blockchain settlement removes the single intermediary by replacing it with distributed consensus. The tradeoff is that finality is granted at block-commit granularity, so settlement latency is tied to block time rather than to how fast the two parties can talk. You also inherit the consensus machinery, and account identity is typically a public-key address with no grounding in physical reality or in who the party actually is over time.
Bare paired-authentication handshakes (two devices mutually authenticating) get you a transient outcome: the handshake succeeds or fails. But an authentication event is not a settlement artifact. Once the session ends, there is often nothing durable a third party can later inspect to reconstruct what was agreed.
The structural gap common to all three: either a third party must be in the loop, or finality is bound to a consensus clock, or you end up with a transient result and no persistent, provenance-bearing record. The disclosed approach targets exactly that gap.
The Architecture
The unit that everything is built on is a governed observation: a signed message that carries, at minimum, an authority credential, a device-identity field, a spatial reference, a temporal reference, a time-to-live, a payload, and a lineage field recording provenance with a cryptographic integrity attestation over those fields. This is the "carried state and lineage" the transaction reconciles against. Identity in this field is not a static key or API secret; per the disclosure it is established through continuity of the device's evolving identity hash over time, which is what lets a receiver judge that this is the same party it has been hearing from rather than a fresh impostor.
A matched-pair transaction is then built from two of these observations:
- A first observation from one party, representing an offer, tender, claim, demand, or commitment.
- A second observation from the other party, representing acceptance, counter-tender, acknowledgment, or fulfillment.
Settlement is the act of recognizing these two as a legitimate pair and binding them. The disclosed primitive does this through a set of cooperating evaluators, each of which you implement:
Spatial proximity check. Verify both observations fall within a governance-policy-defined spatial window. The disclosure lists several window forms: radio-range reachability, a polygon, a radius from a point, membership in a topology node, overlap of both parties' sensor coverage, inter-vehicle range for moving transactions, or a credentialed-venue extent. The point is that the two parties must actually be co-located within the defined window, which grounds the transaction in physical reality rather than in an abstract address.
Temporal proximity check. Verify the second observation arrives within a temporal window relative to the first. Windows may be an absolute duration, tied to defined events, tied to a credentialed authority clock, or adaptive to the transaction class.
Matched-pair recognition. Apply a pairing rule that decides whether these two observations actually constitute a pair. The disclosure enumerates rule forms you can pick from per transaction type: content-field correspondence (matching a transaction identifier or amount), a cryptographic-challenge/response handshake, spatial coincidence, temporal coincidence, an authority-pair requirement (for example, a tolling authority paired with a vehicle operator), a derivation-chain rule where the second observation must cryptographically derive from the first, sequence ordering, or a composite of these.
Per-party authority and admissibility. Verify each party's authority credential, then run the pair through a composite admissibility evaluation that admits it as a settlement candidate.
Cryptographic binding. Produce a cryptographically-bound settlement artifact supporting non-repudiation. In the described binding, each party signs its own observation and a pair-binding composer binds both signatures together with the spatial and temporal proximity attestations. The disclosure also describes optional binding patterns (threshold signatures, hash-commit-reveal, timelocked release, and others) for higher-assurance or privacy-sensitive cases.
Settlement-lineage recording. Record each first observation, second observation, pairing determination, binding, and any negotiation, escrow, failure, dispute, or downstream consumption into the lineage field, so the full history of the settlement can be deterministically reconstructed later.
The result is a persistent settlement record that a downstream consumer can verify was authentically produced by the claimed parties, at the claimed location and time, without asking a clearinghouse. Because the record is provenance-bearing, it is the artifact you route to whoever is authorized to consume it.
The disclosure also describes surrounding machinery you can adopt as the problem demands: a counter-offer / negotiation loop for iterated rounds before terminal settlement; escrow and chained settlement where one settlement is made conditional on another; failure, timeout, and rollback handling for the case where a first observation never gets its matching second observation, or fulfillment falls short; a dispute-resolution path that reassembles the settlement's lineage as evidence; and cross-unit settlement for exchanges denominated in different currencies or in non-currency units such as energy or reserved time.
How to Approach the Build
You are implementing an architecture, so the work is in defining your transaction type precisely and then wiring the evaluators. A reasonable order:
1. Define your observation schema. Decide the payload for your first and second observations, and make sure every observation carries the credential, identity, spatial, temporal, time-to-live, and lineage fields. Everything downstream depends on these being present and signed.
2. Choose your windows. Pick a spatial-window form and a temporal-window form appropriate to your exchange. For a toll, spatial coincidence at the gantry plus a short pass-through duration. For a co-located point-of-sale, a venue extent plus a few seconds. Make these policy values, not hard-coded constants, because they are the knobs you will tune per deployment.
3. Pick your recognition rule. Match the rule to the transaction. A rough illustrative sketch of the pairing decision, faithful to the disclosed evaluator order and offered only to show the shape (not runnable, not a library):
# ILLUSTRATIVE ONLY -- you implement each check
def try_settle(first, second, policy):
if not within_spatial_window(first, second, policy.spatial):
return reject("spatial", first, second)
if not within_temporal_window(first, second, policy.temporal):
return reject("temporal", first, second)
if not recognition_rule(policy).is_pair(first, second):
return reject("not_a_pair", first, second)
if not (authority_ok(first) and authority_ok(second)):
return reject("authority", first, second)
if not admissible(first, second, policy):
return reject("inadmissible", first, second)
artifact = bind_pair(sign(first), sign(second),
spatial_attestation(first, second),
temporal_attestation(first, second))
record_lineage(first, second, artifact) # persistent record
return settled(artifact)
Every reject path is itself lineage-recorded in the disclosed design, with the violation type and the measured-versus-required windows, so failures are auditable rather than silent (unless your policy explicitly chooses a silent-timeout response).
4. Implement the binding and the record format. Decide what your persistent settlement record looks like on disk or in your store, and how each party's signature plus the proximity attestations compose into it. This artifact is the thing a third party verifies, so its non-repudiation properties are load-bearing.
5. Add the failure path before the happy path is "done." Implement timeout detection (a first observation with no matching second), non-acceptance, and failed-fulfillment, and choose a failure response per your policy: silent timeout, notify-and-retry, escalate-to-authority, partial settlement, rollback with lineage, or a compensating transaction.
6. Layer in negotiation, escrow, cross-unit, and dispute only as needed. These are separable mechanisms in the disclosure. Do not build all of them up front; add the counter-offer loop when your exchange actually negotiates, escrow when releases must be conditional, and the dispute path when you need governed challenge of settled pairs.
What This Does Not Give You
This is an architecture, not a drop-in library. There is no package to install and nothing that "just works" out of the box. You implement the observation format, the signing, the window evaluators, the recognition rule, the binding, the persistence, and the failure handling yourself, and you are responsible for the correctness and security of your implementation.
It is disclosed in a patent filing, not benchmarked or productized here. The disclosure characterizes settlement as occurring at mesh-propagation latency rather than at consensus-block latency, but this guide states no throughput, latency, or assurance numbers, because the filing does not, and you should measure your own build rather than assume any.
It also does not fit every problem. The design deliberately requires the two parties to be co-located within a spatial window, so it targets physically-grounded, co-located exchanges. If your two parties are arbitrary internet endpoints with no meaningful shared location, the spatial-proximity mechanism does not map cleanly and this is likely the wrong tool. It also does not remove the need for governance: authority credentials, admissibility policy, and dispute authorities still have to exist and be defined for your domain. And nothing here is legal, financial, or regulatory advice about whether a given settlement is enforceable in your jurisdiction.
Disclosure Scope
The Matched-Pair Settlement approach described in this guide is disclosed in U.S. Provisional Application No. 64/049,409. This article is educational: it explains the disclosed architecture so that a developer can understand and implement it independently. It is not a warranty, not an offer of software, and not a representation that any implementation (yours or ours) is production-ready, secure, or compliant for a particular use. Every mechanism described above is drawn from that filing; where the filing is silent, this guide makes no claim.
