Identity Settlement Tokens (PIST)

Nothing described under this name is implemented. A Physics-Anchored Identity Settlement Token, PIST, is a design in a patent application. There is no endpoint, no table, no SDK call and no dashboard surface for it. Earlier versions of this page described a token format, a minting ceremony, a provenance chain and a transfer protocol as if they existed. They do not, and the fields and timings they named were not drawn from any shipped code.

The filing is PBPIST, application 64/006,819, a provisional continuation-in-part filed 16 March 2026 and pending USPTO examination. It claims settlement tokens whose validity derives from physics-based proof of presence, a three-channel minting gate, a hybrid post-quantum provenance chain and a dual proof-of-presence transfer protocol. Patent claims describe what is claimed, not what runs.

What exists today. The nearest shipped capability is spatial binding, the shield-spatial-bind function. It captures device-side sensor digests within a short window, checks them against a server clock, stores them, and compares a later capture against the enrolled baseline to score replay and device substitution. It produces a stored binding record rather than a transferable token: there is no value, no chain of prior settlements, and no way to hand one to another party.

Three specific claims from the old page are worth correcting, because they describe the platform rather than the patent:

• Hybrid signatures require both layers to verify, the classical one and the ML-DSA one. There is no shipped mode where either alone suffices.
• BLAST tunnels run between a client and the platform. There is no peer-to-peer BLAST transfer; see the BLAST protocol.
• shield_cached_proofs has no provenance chain columns, and no token or proof in the platform consumes the NTP endpoint to anchor itself.

Spatial binding takes digests, never raw sensor data. The client computes them on device and submits them; the platform stores what it is given and never sees a waveform, a coordinate or a reading.

Two temporal checks are enforced, and both are rejections rather than scores:

• The capture window. A capture_duration_ms above 100 milliseconds answers 422 with code NF08_TEMPORAL_WINDOW_EXCEEDED. The value is 100 milliseconds rather than the multi-second window the old page described, and it is checked before authentication.
• Clock drift. The capture_timestamp is compared against the database's own clock through a strict tolerance of 500 milliseconds. Outside it, the response is 422 with code NF08_CLOCK_DRIFT and a body carrying drift_ms, server_time, tolerance_ms, stratum, source and a hint to sync first. See NTP and atomic clock sync.

There is no quorum channel. Nothing requires or consults a second device, and there is no minting gate combining channels with AND logic. Each optional channel that is present simply contributes to the anomaly score at verification.

POST https://api.passkeybridge.io/v1/shield-spatial-bind, authenticated with x-pb-api-key carrying the spatial scope, on an Enterprise tenant. The endpoint is rate limited per caller and edge locked, so a direct call to the Supabase functions host answers 403 Direct access denied.

Enroll stores the fingerprint and creates the baseline binding.

{
  "action": "enroll",
  "tenant_id": "00000000-0000-0000-0000-000000000000",
  "user_hash": "<subject digest>",
  "fingerprint_hash": "<composite digest>",
  "emi_spectral_hash": "<digest>",
  "thermal_variance_hash": "<digest>",
  "device_identifier_hash": "<digest>",
  "capture_duration_ms": 87,
  "capture_timestamp": "2026-09-16T14:30:00.000Z"
}

{
  "status": "enrolled",
  "fingerprint_id": "5d2c...",
  "binding_id": "9a70...",
  "capture_duration_ms": 87,
  "clock_drift_ms": 42,
  "response_ms": 118
}

Enroll answers 201.

Verify stores a new fingerprint, finds the most recent active enrollment for that subject, and scores the difference.

{
  "status": "verified",
  "fingerprint_id": "7f31...",
  "binding_id": "c48b...",
  "anomaly_score": 0,
  "anomaly_reasons": [],
  "passed": true,
  "capture_duration_ms": 91,
  "clock_drift_ms": 12,
  "response_ms": 104
}

The score is additive and each reason is named in anomaly_reasons: a different device digest adds 0.8 as device_mismatch, an EMI and thermal pair identical to the baseline adds 0.5 as exact_replay_suspected, and a jitter digest identical to the baseline adds 0.4 as jitter_replay_suspected. A clean verification scores 0. At or above 0.45 the response status becomes anomaly_detected, passed is false, and the HTTP status is 403. The verification binding is stored either way, so a refusal is auditable.

Errors. 400 for each field validation message; 401 Missing x-pb-api-key header or 401 Invalid or inactive API key; 403 API key lacks 'spatial' scope; 403 with plan_required below Enterprise; 404 with NF08_NO_BASELINE when the subject has no enrollment; 422 for the two temporal checks; 429 when rate limited; 413 Payload too large above 64 KB.

Verify it worked. Enroll, then verify with a fresh capture from the same device: passed is true and anomaly_reasons is empty. The audit log carries nf08.enroll and nf08.verify rows on resource type spatial_binding with the anomaly score and the measured clock drift in their metadata. An Art. 17 erasure deactivates these bindings and clears their signatures; see DSAR workflows.