PulseProof.
Tokens, not templates.

The default move in proof-of-humanity is to scan the user's face, extract a template, and store it in a database the verifier now has to defend forever. Then a vendor sells access to that database under a contract, and a third party gets indemnified, and an auditor signs off on a privacy posture that holds until the breach. The whole architecture is built around something that should not exist: a biometric template that travels.

PulseProof is the inverse. There is no template. The biometric never leaves the device. The verifier receives a short-lived, signed token that says "a real human was here at this moment", scoped to a specific action and verifier, and that is the entire contract. The rest of this essay is how that works in practice, and why the shape of the contract is the load-bearing decision.

Why face-scan vendors are broken by construction

The face-scan model has three problems that PulseProof avoids by construction.

Enrolment creates an identity database that did not exist. Before the verifier knew the user, they did not have a biometric to defend. After enrolment, they do. That database becomes a target for the rest of its life. Encrypting it does not help; the keys are co-located with the systems that need to read it.

Templates are spoofable from the wild. A face is visible. A face is on social media. A face is on a security camera in the lobby. Lifting a face template from a high-resolution photo or a screen replay is now competitive with the best vendors' spoof detection.

The contract conflates "who" with "is human". Most verifiers do not actually need to know who the user is. They need to know that they are not a bot. Conflating the two means every product that needs anti-bot ends up handling identity data it never wanted.

Token, not template

The PulseProof contract is one round trip. The SDK runs a short capture on the device, performs liveness inference locally, and emits a signed verification token. The verifier calls a single verify endpoint with the token. The endpoint validates the signature, the nonce, and the freshness, and returns a boolean with a strength score.

What the token contains:

• A unique session ID and a nonce supplied by the verifier (so tokens cannot be replayed).
• A timestamp and a short TTL (so a captured token expires in seconds).
• A bound verifier public key (so a token issued for verifier A cannot be reused at verifier B).
• A strength score derived from how confident the on-device model was.
• A signature from the device's attestation key chain.

What the token does not contain: any biometric data, any face template, any pulse waveform, any identifying information about the user. The whole point of the design is that an attacker who steals a database of tokens has stolen nothing useful, because tokens expire in seconds and are bound to a verifier they cannot impersonate.

rPPG, briefly

Remote photoplethysmography (rPPG) is the technique of recovering a pulse signal from the camera's view of someone's face. Skin colour changes very slightly with each cardiac cycle as blood volume rises and falls in the capillaries. The change is invisible to the human eye but extractable from a few seconds of video.

PulseProof's capture is roughly two seconds. The on-device model extracts the green channel time series from the face region, denoises it, and looks for the cardiac waveform. If the waveform is present and well-formed, the user is alive. If it is absent or malformed (because the camera is pointed at a photo, a mask, or a screen), liveness fails.

Heart-rate estimates from the same signal land within 1-3 BPM of clinical ECG in our internal benchmarks, comparable to the Apple Watch PPG. The clinical accuracy is a useful byproduct but not the product. The product is the binary "the cardiac signal is present, signed token issued".

The specific spoof-resistance argument

A pulse cannot be lifted from a photo. A pulse cannot be recreated from a mask. A pulse cannot be played back through a screen at the right frequency without producing artifacts a half-decent model catches. The reason the face-scan industry runs a treadmill of new spoof attacks is that the signal they depend on (face geometry) is publicly available. The signal we depend on is not.

That is also why this isn't another biometric in the regulatory sense. A pulse is not an identity. Two different humans have indistinguishable cardiac waveforms at the level of resolution we use. The model is trained to detect aliveness, not to identify the person. There is nothing to enrol and nothing to match against.

Why everything stays on the phone

All the inference happens on the device. The model is small enough to run on CPU or NPU in under a second on modern hardware. The capture is two seconds. The token signing is milliseconds. End to end: under two seconds, with no network round-trip during the capture.

On-device inference is the load-bearing decision. It is what lets us promise that biometric data does not leave the phone. The token contract works only if the inference is local; if we sent the video to a server, "no biometric data leaves the device" would be a lie and the entire privacy posture would collapse. The architecture is designed so that even a malicious update could not exfiltrate the raw signal without users noticing, because there is no path for it to leave.

A boolean, plus a score

The verifier integrates a single SDK call. iOS:

import PulseProofSDK

let result = try await PulseProofSDK.verify(
  apiKey: "pp_live_...",
  nonce: serverProvidedNonce
)

if result.success && result.strength > .standard {
  // proceed with the action
}

The backend then hits a single endpoint:

POST https://api.pulseproof.app/v1/verify
Authorization: Bearer pp_secret_...
Content-Type: application/json

{ "token": "ppt_..." }

→ 200 OK
{ "valid": true, "strength": "high", "issued_at": "..." }

The verifier gets back a boolean and a strength score. They never see the user's face, the user's pulse, or anything resembling a biometric. The integration surface is the smallest possible surface that does the job.

Strength as a first-class parameter

Different actions need different confidence levels. A captcha replacement is happy with a basic liveness signal. A wire transfer is not. PulseProof exposes a strength tier on every token, derived from the on-device model's confidence and the capture quality (lighting, motion, framing). The verifier picks a threshold per action.

The default tiers are:

• Basic: cardiac signal present. Replacement for CAPTCHA, marketplace sign-up.
• Standard: signal present and clean, good capture conditions. Default for most flows.
• High: signal clean, capture excellent, additional anti-spoof signals pass. Financial step-up, healthcare login, AI-agent authorisation.

Aligned, not promised

PulseProof aligns to SOC 2 Type II, GDPR, HIPAA, ISO 27001, PCI DSS, CCPA, NIST, and FedRAMP Ready. The reason the compliance posture is defensible is that the architecture has very little to comply with. We do not store biometric data, so HIPAA does not have a PHI population to govern. We do not transmit personal data cross-border, so GDPR does not have a transfer to authorise. We do not build an identity database, so a data-subject access request returns nothing because there is nothing.

Compliance audits go fast when the answer to most questions is "we do not have that data". The token contract makes the audit a question of cryptographic correctness rather than a question of data-handling discipline.

AI-agent authorisation

The interesting near-term application is not anti-bot. It is AI-agent authorisation. Agents are starting to take actions on behalf of users. The verifier needs a way to know that a real human just consented, freshly, to this specific action. A PulseProof token is exactly that: a signed, time-bound, action-scoped "yes" from a real human.

The contract is identical to the CAPTCHA replacement use case. The semantics are different. The same token says "a real human is here" in one context and "a real human consented" in another. That generality is not a coincidence; it is what falls out of having designed the contract to be small, signed, and scoped.

The decision that mattered most

Out of every architectural choice, the one that mattered most was making the token the product rather than the biometric. Once that was the shape, almost every other decision followed: on-device inference, no enrolment database, a one-call SDK, a compliance posture that audits well. Almost every product I would not want to be PulseProof made the opposite call. They built a face-scan vendor and then tried to retrofit privacy onto it. The privacy posture has to come from architecture, or it does not come at all.