Identity Settlement Tokens

Nothing described under this name is implemented. A physics-anchored identity settlement token is a design in a filed 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 a provisional application filed 16 March 2026. 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. None of these claims is implemented in the product.

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 computed on the device. The client submits them; the server keys each digest with HMAC-SHA-256 under the server-held pepper before storing it and stores the timing in coarse buckets. Each sensor channel arrives as its digest; the request fields are listed below.

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": 90,
  "clock_drift_ms": 42,
  "response_ms": 118
}

Enroll answers 201. The duration in the response is the stored one, rounded up to 10 milliseconds.

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": 90,
  "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 (the comparison keys the digest just sent and also accepts a baseline enrolled before 2026-10-19, which holds the digest as sent), 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, with code NF08_DEVICE_MODEL_REFUSED for a device model and NF08_PLATFORM_NOT_A_FAMILY for a platform outside the families; 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.