> For the complete documentation index, see [llms.txt](https://projectsolo.gitbook.io/solo/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://projectsolo.gitbook.io/solo/protocol-architecture.md).

# Protocol Architecture

## Architecture at a glance

<table><thead><tr><th width="219.5078125">Step</th><th>Description</th></tr></thead><tbody><tr><td><strong>1. User device</strong></td><td>The user completes a short face check through a smartphone or partner-embedded flow.</td></tr><tr><td><strong>2. Encryption layer</strong></td><td>The biometric signal is protected before it is used for verification.</td></tr><tr><td><strong>3. Solo verification network</strong></td><td>Solo checks liveness and uniqueness without exposing raw biometric data to the partner.</td></tr><tr><td><strong>4. Proof / attestation</strong></td><td>Solo returns a proof that the user is human, unique, and present for the requested context.</td></tr><tr><td><strong>5. Partner application</strong></td><td>The partner uses the proof to allow, deny, count, reward, or continue the relevant action.</td></tr></tbody></table>

## Core technical primitives

* **Mobile-first biometric capture:** users verify through the smartphone they already have, without dedicated scanners or specialized hardware.
* **zkFHE privacy model:** Solo’s positioning is based on encrypted biometric comparison, protecting raw biometric data from exposure.
* **1P1A enforcement:** Solo supports one-person-one-account or one-person-one-action style policies in the relevant platform context.
* **Decentralized verification network:** Solo is designed to avoid a single centralized point of control or breach.
* **Proof-based output:** the partner receives a verification signal instead of personal identity data.

## Verification flow

<table><thead><tr><th width="160.4140625">Step</th><th>Description</th></tr></thead><tbody><tr><td><strong>1. Capture</strong></td><td>The user opens the Solo app or a partner-embedded SDK and completes a brief facial scan through a smartphone camera.</td></tr><tr><td><strong>2. Encrypt</strong></td><td>Biometric data is encrypted using zkFHE before transmission or comparison.</td></tr><tr><td><strong>3. Verify</strong></td><td>The encrypted biometric is matched against Solo’s encrypted identity registry across the verification network. The result is pass/fail without raw data being shared.</td></tr><tr><td><strong>4. Attest</strong></td><td>A proof of humanity is issued. The partner receives a verified signal, not personal data.</td></tr></tbody></table>

## Continuous verification

Solo can be used beyond initial signup. It can support mid-session re-verification so a platform can confirm that the human who started a session is still present when the session continues or reaches a sensitive action.

* **Time-based triggers:** re-check during longer sessions.
* **Action-based triggers:** re-check before sensitive or high-value actions.
* **Random triggers:** introduce unpredictable checkpoints so scripts cannot simply pass login and automate the rest.
* **On failure or no response:** the partner can pause, stop, or deny the session according to its own product policy.

## On-chain and off-chain usage

Solo can support off-chain API verification for applications that enforce decisions in their own backend. For Web3 projects, the earlier Solo draft also describes a PoH Verifier contract that Solidity contracts can call before executing token claims, governance votes, or reward distribution. Final contract addresses and interfaces should come from Solo engineering, not from this public overview.