What You Are Building
You are building a settlement layer for physical-world exchanges between two parties who meet in the same place at the same time: a vehicle and a charge point, a vehicle and a toll gantry, a prosumer feeding energy back and a consumer drawing it. The goal is that the two parties reconcile the exchange directly, produce a persistent record that downstream consumers (billing, regulators, the two parties' own histories) can trust, and do all of this without a central clearinghouse standing between them and without waiting on distributed consensus to reach finality.
This is a recurring problem for anyone designing EV charging networks, road tolling, or prosumer energy markets. The physical event is inherently local and bilateral: one car, one charger, one moment. Yet the conventional settlement path drags that local event out to a remote intermediary, adds counterparty risk and per-transaction overhead, and often loses the tie between the money and the physical fact that money was owed. The approach below keeps settlement where the event happened.
The underlying method is disclosed in U.S. Provisional Application No. 64/049,409 as the "Matched-Pair Settlement" primitive. What follows is the architecture, traced to that disclosure, that you would implement yourself.
Why the Obvious Approaches Fall Short
There are three common ways teams attempt this today, and each has a real structural gap for local, bilateral, physical-world exchange.
Centralized payment processors and clearing networks. A card processor or a tolling clearinghouse settles by routing the transaction through a third-party intermediary. This works and is widely deployed, but the intermediary holds counterparty risk and carries the operational overhead of managing it. Consent is typically bound once, at account setup, so each individual pass through a gantry inherits an implicit, pre-authorized consent rather than an explicit per-transaction one. And the transaction is addressed to abstract account identifiers with no structural grounding in the physical fact that a specific vehicle was at a specific gantry at a specific second.
Blockchain and distributed-ledger settlement. These settle through distributed consensus. Consensus gives you a shared record without a named intermediary, but finality arrives at block-commit granularity, which is minutes-scale latency in practice, and public-key-pair account addressing again detaches the ledger entry from the physical event. For a car rolling through a toll point, block-time finality is the wrong shape.
Paired-authentication handshakes. Protocols that authenticate two endpoints to each other do produce a bilateral, local interaction. But the typical outcome is a transient authentication result. Once the session ends, there is no persistent, portable settlement artifact that a billing system or an auditor can later consume as durable evidence of what was exchanged.
The gap common to all three: none produces a durable, self-describing settlement record that is both directly bilateral and grounded in physical space and time, carrying its own provenance so a downstream consumer can verify it without asking an intermediary. That combination is what the architecture below targets.
The Architecture
The disclosed approach treats settlement as a matched pair of governed observations. Everything below traces to the Chapter 20 disclosure of Application No. 64/049,409.
The two observations. A first party emits a governance-credentialed observation representing an offer, tender, claim, demand, or commitment. A second party emits a governance-credentialed observation representing acceptance, counter-tender, acknowledgment, or fulfillment. For tolling, the disclosure gives the concrete case of a tolling authority paired with a vehicle operator; for energy, an energy transfer denominated in kilowatt-hours. Each observation carries an authority credential identifying the party's source under an authority taxonomy, along with spatial and temporal references.
The window. A spatial-proximity evaluator verifies both observations fall inside a governance-policy-defined spatial window, and a temporal-proximity evaluator verifies they fall inside a temporal window. This is the mechanism that grounds the transaction in physical reality: the parties must be co-located when they observe. The disclosure enumerates window forms you choose among per deployment, including radio-range windows, radius-from-point windows centered on a fixed location (natural for a charge point), and vehicle-proximity windows defined by inter-vehicle range for moving transactions. Its worked tolling example requires spatial-coincidence at the tolling marker plus temporal-coincidence within the vehicle's pass-through window.
The pairing rule. A matched-pair recognition engine applies governance-policy-defined pairing rules that decide whether a received first and second observation actually constitute a pair. The disclosure lists rule forms you can compose: content-matching (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, composite spatial-temporal, authority-pair (requiring, for example, tolling-authority paired with vehicle-operator), and derivation-chain rules where the second observation must cryptographically derive from the first. These are configurable per transaction type, so tolling, commerce, and custody handoffs each get their own rule.
Admissibility and per-party authority. A per-party authority evaluator verifies each party's credential, and a composite admissibility evaluator admits the matched pair as a settlement candidate. Only an admitted pair proceeds.
Cryptographic binding. A binding mechanism produces a cryptographically-bound settlement artifact supporting non-repudiation. In the disclosed binding, each party signs its own observation, a pair-binding composer binds both signatures, and a spatial-temporal attestation composer binds that cryptographic pair together with the spatial-proximity and temporal-proximity attestations. The result is a record a downstream verifier can check to confirm the settlement was authentically produced by the claimed parties at the claimed location and time. The disclosure also describes optional binding patterns you can select, including threshold signatures, hash-commit-reveal, timelocked release, and zero-knowledge or anonymous-credential binding for cases where transaction content should not be exposed to unauthorized parties.
Lineage. A settlement-lineage recorder records each first observation, second observation, pairing determination, binding, and any negotiation, escrow, failure, dispute, and downstream consumption. This is the "carried state and lineage" the pair reconciles against. It sits inside the broader five-property governance chain the disclosure imposes on every governed mutation: authority-credentialed observation, evidential weighting, composite admissibility evaluation, governed execution, and lineage-recorded provenance. Settlement records enter that chain as matched-pair attestations, which is what lets a downstream consumer trust a record without a clearinghouse: the record carries its own provenance.
The disclosure states plainly how this differs from the alternatives above: it settles directly between the transacting parties without an intermediary; it produces observation-granularity settlement at mesh-propagation latency rather than block-commit finality; it yields a persistent, governance-chain-preserving record rather than a transient authentication outcome; and it produces explicit per-transaction bilateral consent through the paired observations rather than implicit account-level consent.
How to Approach the Build
The following ordered steps mirror the disclosed components. You implement each yourself; the disclosure defines the shape, not the code.
Define your party classes and credentials. Decide who transacts: for tolling, an infrastructure agent (the gantry, with fixed credentials) and a vehicle operator; for prosumer energy, two operators plus possibly a regulatory authority. Each party needs an authority credential under an authority taxonomy. Settle identity first, because every later step keys off it.
Specify the observation content schema. Define the fields of the first and second observations for your transaction type. A tolling first observation might carry the marker identity, rate, and pass-through window; the second, the vehicle's acknowledgment. An energy settlement carries a kilowatt-hour quantity as a commodity-denominated unit.
Choose your spatial and temporal windows. Pick the window forms from the disclosed plurality that match your physics: radius-from-point at a fixed charger, vehicle-proximity range for moving toll transactions, and a temporal window sized to the pass-through interval. Verification uses your position and time sources with position and temporal lineage preserved.
Write the matched-pair recognition rule. Compose the rule from the disclosed forms. An illustrative, spec-faithful sketch of the pairing decision (not runnable code):
# illustrative only, faithful to the Chapter 20 recognition rule plurality def is_matched_pair(first_obs, second_obs, policy): return (authority_pair_ok(first_obs, second_obs, policy) # e.g. tolling-authority + vehicle and within_spatial_window(first_obs, second_obs, policy.spatial) and within_temporal_window(first_obs, second_obs, policy.temporal) and content_or_handshake_matches(first_obs, second_obs, policy))Add per-party authority and composite admissibility checks before you bind anything. A pair that fails either is not a settlement candidate.
Implement the cryptographic binding. Have each party sign its observation, bind the two signatures, then bind in the spatial-temporal attestations so the artifact is verifiable as to who, where, and when. Start with simple-signature binding; add threshold, commit-reveal, or timelocked patterns only where your assurance or privacy needs demand them.
Record lineage and route the record. Emit the settlement record into your lineage store and route it to authorized downstream consumers (billing, the parties' histories, regulators where required).
Handle the unhappy paths. Implement the disclosed failure handling: a timeout detector for a first observation that never gets its second within the window, a non-acceptance detector for explicit rejection, and rollback with lineage for partial state. Choose failure responses per policy (silent timeout, notify-and-retry, escalate-to-authority, compensating transaction). If your market negotiates price or terms, add the counter-offer loop with its bounded round count; if release depends on an external condition, add escrow with the release evaluator.
What This Does Not Give You
This is an architecture, not a drop-in library. There is no package to install and no code that "just works" off the shelf. The disclosure defines interfaces and mechanisms; you write the implementation, choose concrete cryptographic primitives, and integrate your own position, time, and identity sources.
It is not a benchmarked or productized system. The disclosure describes settlement at mesh-propagation latency and observation granularity as an architectural property; it does not supply performance numbers, and this guide does not claim any. Treat throughput, latency, and assurance as things you must measure in your own deployment.
The approach is scoped to bilateral, physically co-located exchange. It requires the two parties to be inside a spatial-temporal window, which is exactly why it fits charging and tolling but is not a fit for purely remote transactions with no physical grounding. Three-or-more-party exchanges are out of scope for the matched-pair primitive itself; the disclosure routes those to a separate N-party coordination primitive. Several capabilities here (cross-unit denomination, cross-jurisdiction translation, continuity-preserving identity) are described as compositions with other disclosed primitives, so a faithful build depends on those pieces too.
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 the architecture and how a developer might approach implementing it. It is not a warranty, a specification of a shipping product, or an offer of software, and no downloadable library or SDK is implied. Every mechanism described above is drawn from that filing; where the filing does not state a parameter, guarantee, or performance figure, this guide does not either.
