How It Works

The full verification pipeline, end to end.

// VERIFICATION FLOW

Three stages, seven steps.

From behavioral challenge to on-chain proof. No biometric data leaves your device at any point in this pipeline.

01 — Challenge

A random nonsense phrase and Lissajous curve generated fresh for each session. No two sessions share the same challenge.

Each session generates a unique phrase from phonetic syllables and a unique Lissajous curve from random mathematical parameters. The user speaks the phrase while tracing the curve for 12 seconds. The challenge elicits natural behavioral data (voice prosody, hand tremor, touch pressure) rather than testing memory or speed.

02 — Capture

Three sensor streams record in parallel: voice, touch, and motion. 12 seconds of simultaneous behavioral data.

The Pulse SDK accesses the device microphone, accelerometer, gyroscope, and touch digitizer. All sensors record in parallel for 12 seconds. Raw data stays in device memory and never reaches a network interface. On desktop, motion sensors are unavailable. Mouse pointer dynamics provide equivalent kinematic features.

03 — Extract + Score

Speaker features (F0, jitter, shimmer, HNR, formants), jerk analysis, statistical condensing. Plus entropy scoring to detect synthetic data.

Audio: fundamental frequency, vocal jitter, shimmer, harmonics-to-noise ratio, and formant ratios. Per-feature entropy detects TTS artifacts. Motion and touch: jerk and jounce analysis with jitter variance scoring. Real human tremor fluctuates over time, synthetic data stays constant. On desktop, mouse dynamics replace motion sensor data.

04 — Hash

SimHash projects features into a 256-bit fingerprint. Same-user fingerprints cluster; imposters diverge.

The expanded feature vector (including entropy and jitter metrics) is passed through SimHash using random hyperplane projections. The output is a Temporal Fingerprint. Two fingerprints from the same person have small Hamming distance. The entropy features mean synthetic data produces a different fingerprint than real behavioral data.

05 — Commit

Poseidon(fingerprint || salt) produces the TBH commitment. The fingerprint and salt stay on-device.

A large cryptographically-secure salt is generated. The Poseidon hash function (chosen for ZK-circuit efficiency over BN254 field elements) takes the fingerprint concatenated with the salt to produce H_TBH. The commitment and ZK proof are transmitted. The fingerprint and salt remain on-device, encrypted.

06 — Prove

Groth16 ZK proof: distance is within the valid range. Not too similar (replay), not too different (imposter).

The proof verifies three statements: both commitments are valid Poseidon hashes of real fingerprints, the Hamming distance falls below the maximum threshold (natural human variation), and the distance exceeds a minimum threshold (blocks perfect replay where a bot submits identical data). The verifier learns nothing about the actual fingerprints.

07 — Verify

Proof verified on Solana. Anchor updated. Progressive Trust Score recalculated from verification history.

The proof is submitted via the IAM relayer (walletless) or the user's wallet (wallet-connected). The verifier checks the Groth16 proof on-chain. On success, the Anchor stores the verification timestamp in a rolling history. Trust Score recalculates using recency weighting and regularity analysis — consistent verifications over weeks score higher than rapid bursts.

// PROTOCOL COMPONENTS

Four layers, one proof

Pulse SDK

Client-side capture and proving

A TypeScript library that runs on the user's phone or browser. It captures sensor data, extracts features, generates the TBH commitment, and produces the ZK proof. The raw biometric data never leaves this library.

  • Browser and React Native support
  • Audio, IMU, and touch capture in parallel
  • On-device Groth16 proof generation
  • Walletless mode (relayer) and wallet-connected mode

ZK Circuit

Hamming distance verification

A Groth16 circuit that proves two Poseidon-committed TBH values are within Hamming distance t of each other. The circuit runs at proving time on the user's device. The verifier learns only that the threshold check passed.

  • Groth16 over BN254 curve
  • Poseidon hash for ZK efficiency
  • Under 200K compute units on-chain
  • Proof generation targets under 5 seconds on mobile

On-Chain Programs

Three Solana programs

The iam-verifier program checks ZK proofs. The iam-anchor program manages non-transferable identity tokens (SPL Token-2022). The iam-registry tracks Trust Scores, validator staking, and protocol configuration.

  • Anchor framework with full constraint validation
  • Non-transferable token via Token-2022 extension
  • Trust Score from verification count and age
  • PDA-derived identity (one per wallet)

Executor Node

Off-chain validation service

A Rust service that listens for on-chain verification events, issues challenges, relays attestations, and manages the Anonymity Ring. Handles walletless transaction submission via the relayer API.

  • Solana RPC subscription via geyser/websocket
  • Challenge issuance and attestation relay
  • Walletless relayer for integrator-funded transactions
  • Configurable CORS and rate limiting
// PRIVACY GUARANTEES

What the protocol guarantees

On-device processing

Sensor capture, feature extraction, hashing, and proof generation all run on the user's phone. No server computes on biometric data.

No biometric storage

Raw audio, motion, and touch data are destroyed after the Temporal Fingerprint is computed. No database holds voice samples or movement traces.

ZK proof is the only output

The Pulse SDK transmits a Groth16 proof and a Poseidon commitment. The fingerprint, salt, and raw sensor data never cross the network.

No identity mapping

The protocol proves 'you are human,' not 'you are a specific person.' The TBH is pseudonymous. It does not link to a name, email, or social account.

One-way commitment

Poseidon(fingerprint || salt) is computationally irreversible. The commitment cannot be decoded back into the original behavioral fingerprint.

GDPR and EU AI Act aligned

Behavioral verification (not identification) falls outside the strictest AI Act categories. Data minimization is guaranteed by architecture, not policy.

// SECURITY MODEL

How IAM resists bots.

No single verification proves humanness. IAM makes Sybil attacks economically irrational through layered defenses that increase the cost of faking identity at scale.

Minimum Distance Constraint

The ZK circuit enforces a minimum Hamming distance between consecutive fingerprints. Perfect replay is rejected at the proof level. A bot submitting identical synthetic data twice gets blocked before reaching the chain.

Behavioral Entropy Scoring

The feature extraction pipeline measures Shannon entropy and jitter variance across each sensor stream. Real human data has moderate, fluctuating entropy. Synthetic data from TTS engines or scripted inputs is too uniform and gets flagged before hashing.

Progressive Trust Score

Trust Score rewards consistency over time, not volume. 100 verifications in one day scores lower than weekly verifications over 3 months. Recency weighting and regularity bonuses make bot farming slow and expensive.

Per-Session Randomness

Each verification generates a unique random phrase and Lissajous curve. No two sessions share the same challenge. The challenge elicits involuntary behavioral patterns (voice prosody, hand tremor, touch pressure) that are harder to synthesize than the words themselves.

Multi-Modal Capture

Three independent sensor streams record in parallel: microphone, pointer/touch digitizer, and device motion (where available). A bot needs to fake realistic voice, tremor, and touch pressure simultaneously. Spoofing one modality is feasible. Spoofing all three with consistent behavioral entropy is not.

Economic Disincentives

Each verification costs ~$0.01 on-chain. Each wallet requires SOL. Maintaining thousands of fake identities over months, re-verifying regularly to build trust, costs real money. The attack costs more than the value it extracts.

// VERIFICATION MODES

Two modes, graduated trust.

Traditional captcha answers “is this session human?” IAM answers a harder question: “is this the same human, and how long have they been proving it?” The protocol provides the signal. The integrator sets the threshold for their use case.

Wallet-Connected

High trust

Connect a Solana wallet. Your IAM Anchor (non-transferable token) is tied to that wallet. Behavioral fingerprint stored on your device, commitment stored on-chain. Trust Score accumulates over time and is visible to every integrator on-chain. This is the persistent, portable identity. Each wallet requires funded SOL, and re-verification costs compound, making bot farms economically unsustainable at scale.

Walletless

Graduated trust

No wallet, no crypto knowledge needed. First verification acts as a liveness check: the protocol confirms a human produced the behavioral data, but has no prior fingerprint to compare against. Returning verifications build device-bound consistency as behavioral drift is checked against the locally stored (encrypted) fingerprint. The identity is application-scoped and ephemeral. No on-chain Anchor, no portable Trust Score. Clear the browser, switch devices, and the history is gone.


Zero data. On-chain proof.