> 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/privacy-security-data-handling.md).

# Privacy Security Data Handling

## Privacy objective

Solo’s privacy objective is to prove that a living, unique human is present without turning the partner into a biometric data custodian and without making legal identity the default requirement.

## Data path

<table><thead><tr><th width="199.77734375">Step</th><th>Description</th></tr></thead><tbody><tr><td><strong>1. On the user device</strong></td><td>The user completes a face check through a smartphone. The sensitive biometric signal is protected before the partner receives any result.</td></tr><tr><td><strong>2. Inside Solo verification</strong></td><td>Solo verifies liveness and uniqueness using its protected verification architecture.</td></tr><tr><td><strong>3. Back to the partner</strong></td><td>The partner receives a proof or verified signal that can be used to make an application decision.</td></tr><tr><td><strong>4. Inside the partner system</strong></td><td>The partner should only keep the operational record it needs to show that a proof was checked and a product decision was made.</td></tr></tbody></table>

## What Solo does not require by default

* No raw biometric database for partners to manage.
* No government ID requirement for the default proof-of-humanity flow.
* No specialized hardware such as dedicated scanners or physical verification devices.
* No default requirement to reveal legal name, nationality, address, or passport number to prove humanity.

## What the partner receives

At this product-documentation level, the partner receives a verified signal or proof that a user is human, unique, and present. Exact endpoint names, webhook schemas, proof field names, contract interfaces, and SDK instructions should live in the official developer reference once confirmed by engineering.

## Data-handling principles for partners

* Ask for proof only when the product decision genuinely requires verified human presence.
* Do not request or store biometric material from Solo users.
* Separate Solo proof-of-humanity from any optional KYC or regulated identity workflow the partner may run independently.
* Keep partner-side records minimal: store the decision and proof reference provided by the official Solo integration, once confirmed by engineering.
* Explain to users that Solo proves humanity and uniqueness by default, not legal identity.

## Security logic

* **Bot or script activity:** require a live human check before account creation, task access, claim, vote, reward, or session continuation.
* **Duplicate accounts:** use Solo to enforce one verified human within the relevant platform or campaign context.
* **Account handoff:** use continuous verification during long or high-value sessions.
* **Partner breach risk:** minimize what partners receive and store; do not pass raw biometric data into partner systems.