What You Are Building
You want two parties to settle a physical-world exchange directly, on their own, with a durable record that a third party can later trust. Concretely: a rooftop solar prosumer sells surplus kilowatt-hours to a neighbor; an electric vehicle discharges into a building during a demand peak and needs to bill for it; a generator retires a batch of carbon credits and a buyer needs proof the retirement actually happened and cannot be double-counted.
The common shape is a bilateral exchange grounded in physical reality: a specific amount of a specific commodity moved between two specific parties at a specific place and time, and both sides need a settlement record that survives audit. This guide describes an architecture, the Matched-Pair Settlement inventive step disclosed in U.S. Provisional Application No. 64/049,409, that produces that record from two paired observations, one from each party, without a central clearinghouse standing in the middle and without waiting for a distributed ledger to reach consensus.
Why the Obvious Approaches Fall Short
The default approaches are all real and all workable in their own domains. The point here is not that they are broken, but that each carries a structural cost that gets heavy when you scale physical-world bilateral exchanges.
A central clearinghouse or payment processor settles by putting a trusted intermediary between the two parties. This works and is well understood, but the intermediary holds counterparty risk, adds per-transaction overhead, and becomes a single operational and regulatory dependency for every trade on the network. For a neighborhood energy market with thousands of small metered exchanges, the intermediary economics do not fit well.
A blockchain or distributed ledger removes the named intermediary but replaces it with distributed consensus. Finality arrives at block-commit granularity, typically seconds to minutes, and the ledger state is replicated to every consensus node. For high-frequency, low-value energy micro-exchanges this consensus overhead and latency are a poor match, and carbon markets in particular need a settlement record that is directly consumable by a regulator rather than reconstructed from chain surveillance.
A paired-authentication handshake (the kind of challenge-response you already use to prove two devices met) gets you the physical-proximity part but produces a transient authentication outcome. It confirms the meeting happened and then evaporates. It does not leave behind a persistent, disputable, auditable settlement artifact.
The structural gap is this: none of the defaults give you a direct two-party settlement that is simultaneously physically grounded, produces a durable non-repudiable record, and carries its own audit lineage, without a standing intermediary or a consensus round.
The Architecture
The disclosed approach treats settlement as a matched pair of governed observations. Every claim in this section traces to the filed disclosure.
Two observations, two parties. A first party emits a first observation representing an offer, tender, claim, demand, or commitment. A second party emits a second observation representing acceptance, counter-tender, acknowledgment, or fulfillment. In the disclosure's energy-transfer instance, the first observation is the energy-receiver's demand directive and the second observation is the energy-source's delivered-energy observation. For carbon credits, settlement is denominated in a rights-denominated unit (the disclosure lists carbon credits alongside spectrum rights, water rights, and fishing quotas as rights-denominated settlements). Each observation is governance-credentialed, meaning it carries an authority credential identifying the party's authority to make it.
A recognition engine pairs them. A matched-pair recognition engine applies governance-policy-defined pairing rules that map a first and second observation into a bilateral-exchange record. The disclosure describes several rule forms you can compose: content-matching (pair by a shared transaction identifier, amount, or resource identifier), cryptographic-handshake (the first observation commits to a challenge, the second produces the response), spatial-coincidence, temporal-coincidence, authority-pair (a specific pair of credential types must meet, for example a metered energy source paired with a consuming unit), and derivation-chain (the second observation must cryptographically derive from the first). These are configurable per transaction type.
Proximity windows ground it in physical reality. A spatial-proximity evaluator verifies the two observations fall within a governance-policy-defined spatial window, and a temporal-proximity evaluator verifies they fall within a defined temporal window. This is what separates the approach from settling against abstract digital addresses: the parties must actually be co-located within the window at the time of their observations, producing what the disclosure calls physical-reality-grounded transactions. Spatial windows can be radio-range, a polygon, a radius from a point, or a credentialed-venue extent, among others; temporal windows can be an absolute duration from the first observation, or event-relative. A window violation does not silently fail; it produces a governance-chain-preserving rejection recording the violation type, both observations, and the measured versus required windows.
Admissibility, then binding. A per-party authority evaluator checks each party's credential, and a composite admissibility evaluator admits the matched pair as a settlement candidate. A cryptographic binding mechanism then produces a cryptographically-bound settlement artifact supporting non-repudiation: each party signs its own observation, a pair-binding composer binds both signatures, and a spatial-temporal attestation composer binds the pair to the proximity attestations. The disclosure describes optional binding patterns you can select, including threshold-signature, zero-knowledge (verifiable without disclosing content to unauthorized parties), hash-commit-reveal, and timelocked-release.
The record carries its own lineage. This is the load-bearing idea. A settlement-lineage recorder records the first observation, the second observation, the pairing determination, the binding, and any negotiation, escrow, failure, dispute, and downstream consumption, all in a governance-chain lineage field. The settlement artifact is therefore not a bare receipt; it carries the reconstructable history of how it came to exist. Downstream consumers, including regulators, can verify that the settlement was authentically produced by the claimed parties at the claimed location and time.
Everything else composes onto that spine. Around the core pair, the disclosure adds: a counter-offer and negotiation mechanism for bounded iterated rounds (price negotiation, term negotiation, partial-fulfillment) before terminal settlement; an escrow and chained-settlement mechanism where one settlement can be made conditional on another (useful for supply-chain or cross-currency steps), with each chain link carrying lineage upstream and downstream; a settlement-failure, timeout, and rollback mechanism (a timeout detector for first observations that never get a match, plus responses ranging from silent-timeout to compensating-transaction to dispute-escalation); a dispute-resolution mechanism where either settled party can raise a governance-credentialed challenge and an evidentiary-lineage assembler produces the full lineage as evidence; and a cross-currency, cross-unit, and fractional settlement mechanism that lets you denominate in kilowatt-hours, carbon credits, or fiat and convert between them with exchange-rate lineage.
How to Approach the Build
You are implementing this yourself. The disclosure describes the architecture; the following is a sensible order to build it in.
Define your two observation schemas. Decide, for your domain, exactly what the first and second observations contain. For a prosumer energy sale: the receiver's demand directive (requested kWh, price ceiling, meter identity) and the source's delivered-energy observation (metered kWh delivered, source meter identity, timestamp). For a carbon-credit retirement: the retirement claim and the acknowledgment, denominated in the rights unit.
Choose and encode your recognition rule. Pick from the rule forms above and compose them. A metered energy exchange plausibly wants authority-pair (source credential meets consumer credential) plus content-matching on a transaction identifier and amount, plus temporal-coincidence. Write this as an explicit, testable predicate. An illustrative interface sketch, faithful to the disclosed roles but not a working library:
// Illustrative only. You implement these against your own credential // and transport layer; this is not a shipped API. isMatchedPair(first, second, policy): authorityPairOK(first.cred, second.cred, policy) and contentMatches(first.txId, second.txId) and amountsReconcile(first.demand, second.delivered, policy.tolerance) and withinTemporalWindow(first.time, second.time, policy.window)Implement the proximity evaluators. Define your spatial window (radio-range for two co-located meters, a polygon for a microgrid boundary) and temporal window (an absolute duration after the demand directive). Make violations produce a recorded rejection, not a dropped packet.
Add authority and admissibility checks. Verify each party's credential before you even attempt to bind. Then run a composite admissibility check that gates the pair on your policy.
Build the binding and the settlement record. Have each party sign its observation, bind the two signatures together with the proximity attestation, and emit a settlement artifact. Start with simple-signature binding; reach for threshold or zero-knowledge binding only where your assurance or privacy requirements demand it.
Record lineage from the first step, not as an afterthought. Every observation, pairing decision, rejection, binding, and downstream delivery goes into the lineage field. This is what makes the artifact auditable and disputable later; retrofitting it is painful.
Layer negotiation, escrow, failure handling, and disputes as needed. Not every deployment needs all of them. A zero-fee neighborhood energy swap may need only timeout handling; a carbon-credit exchange with regulatory exposure will want dispute resolution and evidentiary lineage assembly.
What This Does Not Give You
This is an architecture, not a drop-in library. There is no package to install and no downloadable SDK implied here; you build the observation schemas, the recognition engine, the proximity evaluators, the credential system, the binding, and the lineage recorder yourself, against your own transport, metering, and identity infrastructure.
It is a disclosed architecture, not a benchmarked or productized system. The filing describes how the mechanism is structured and what it is intended to produce; it is not a performance claim you should treat as measured, and nothing here is proven in production by this guide.
The approach also has a real boundary of applicability. It settles bilateral exchanges between two parties who can be brought within a spatial and temporal window. A settlement among three or more parties is, per the disclosure, a different N-party coordination concern, not this primitive. If your parties are never physically or topologically co-located within a definable window, the proximity grounding that gives this approach its strength does not apply, and a different design is more appropriate. And every guarantee here depends on the credential and authority system you supply; the settlement is only as trustworthy as the authority taxonomy behind the observations.
Disclosure Scope
The Matched-Pair Settlement approach described in this guide is disclosed in U.S. Provisional Application No. 64/049,409. This guide is educational: it explains an architectural approach so that a skilled developer can understand and implement it themselves. It is not a warranty, a specification of a shipping product, or an offer of software, and it does not grant any license. Any implementation, and its correctness, security, and regulatory compliance, is the responsibility of the party who builds it.
