> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vana.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Intro to Vana
> An open protocol for private, user-owned data — sovereign data infrastructure for the AI economy.
Vana is a peer-to-peer network and open protocol for **user-controlled data portability**. A user owns their data and grants access on their own terms — and the access decision, the encryption behind it, and the payment for it are all first-class, protocol-level concerns. On top of that base, pooled confidential compute (DataDAOs) is one application a builder can choose to run, not a requirement.
Building an app on Vana? Start with the [Build a Vana App](/build-a-vana-app) guide — request user-approved data, read it from the user's Personal Server, and pay protocol fees from an app escrow balance.
## The stack
```mermaid theme={null}
flowchart TB
publicSrc["Public data sources
Instagram, X, Reddit, …"]:::ingress
userAcct["The user's own accounts
(authenticated, same sources)"]:::ingress
pipe["Data Pipe API
ODL-operated"]:::odl
subgraph apps["Vana apps — each bundles a Personal Server"]
direction LR
web["Web app"]:::sdk
desktop["Desktop app · Data Connect"]:::sdk
end
publicSrc -->|public data| pipe
pipe -->|server-side| web
userAcct -->|deep connector on the user's host,
through the user's own browser| desktop
apps --> protocol
subgraph protocol["Vana Protocol — DP RPC · L2 rollup or L1"]
prims["Identity · Permissions · Fees
PGE · Schemas · Files · DLP contracts"]:::protocol
end
hosted["Bring your own compute
user-controlled (future)"]:::sdk
storage["Cloud Storage
encrypted"]:::odl
gateway["Context Gateway
ODL · OAuth, USD API"]:::odl
tee["DLP / TEE network
pooled confidential compute"]:::neutral
consumers["Builders & consumers
apps, agents, enterprises, AI labs"]:::neutral
protocol --> storage
hosted --> protocol
consumers --> gateway --> protocol
tee --> protocol
classDef protocol fill:#DCE4FF,stroke:#4141FC,color:#11104a;
classDef odl fill:#FCE0E8,stroke:#E5527A,color:#5a1228;
classDef sdk fill:#FFF3D1,stroke:#E6A700,color:#5c4400;
classDef ingress fill:#E2F4DC,stroke:#34A853,color:#14431f;
classDef neutral fill:#EEF1F5,stroke:#9AA4B2,color:#1f2937;
```
## How it stays user-owned
The user brings their data in one of two ways: **public data through the web**, or deeper **authenticated data through the desktop app**. The desktop connector runs **on the user's own browser, on their host** — the data is not sent anywhere; it stays on the user's device.
From there, data only ever moves while **encrypted**, and is only ever decrypted against a permission the user granted:
1. The user's **Personal Server** runs locally — in a browser tab on the web, or bundled into the desktop app. It **encrypts the data** and syncs the ciphertext to hosted **cloud storage**. ODL stores data it cannot read.
2. When a builder presents a **grant**, the encrypted data is decrypted under that grant. Today the **Personal Server is the only entity that decrypts**; with [Protocol-Governed Encryption](/protocol-reference/encryption-pge) the grantee decrypts and PGE enforces the release. Either way, decryption happens only against a valid onchain permission.
3. **Without PGE (today):** the Personal Server returns the data **directly to the builder**. **With [PGE](/protocol-reference/encryption-pge):** the grantee receives a key from PGE and decrypts the data itself, so the Personal Server does **not** return the data directly. In both cases the **grant is recorded on-chain**, and the read is recorded in an **access log** the user can review.
```mermaid theme={null}
flowchart LR
collect["Collect data
public (web) · deep (desktop, user's browser)"]:::ingress -->|stays on the user's device| ps["Personal Server (local)
encrypts · only decryptor"]:::sdk
ps -->|"① ciphertext"| storage["Cloud storage
ODL · stores ciphertext only"]:::odl
builder["Builder with a grant"]:::neutral -->|"② grant"| ps
storage -->|"③ encrypted data"| ps
ps -->|"④ decrypted data, returned directly"| builder
ps -.->|grant anchored onchain · read in access log| chain["On-chain
DP RPC · L1"]:::protocol
classDef protocol fill:#DCE4FF,stroke:#4141FC,color:#11104a;
classDef odl fill:#FCE0E8,stroke:#E5527A,color:#5a1228;
classDef sdk fill:#FFF3D1,stroke:#E6A700,color:#5c4400;
classDef ingress fill:#E2F4DC,stroke:#34A853,color:#14431f;
classDef neutral fill:#EEF1F5,stroke:#9AA4B2,color:#1f2937;
```
That is what "user-owned" means here: collection stays on the user's device, storage holds only ciphertext, decryption happens only against an on-chain permission, and every access is authorized by an on-chain grant and recorded in an access log. Note the boundary: once data is returned to a builder, that copy is in their hands — the grant and log govern *whether* a read happens and leave a record of it, not what a builder does with data it already received.
### Who controls each layer
The stack diagram above is colored the same way: **blue = protocol**, **yellow = runs under the user (Vana SDK)**, **pink = operated by ODL**, **green = community connectors**.
| Layer | What it covers | Who controls it |
| ------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------ |
| **Protocol** | DP RPC and its onchain primitives: identity, permissions, fees, PGE, schemas, files, DLP contracts | The network / onchain |
| **Vana SDK** | Encryption, decryption, permissions, identity — the client logic in the user's app and Personal Server | The user (runs on their device/infra) |
| **Data connectors** | Extraction scripts per source | Open source, community-controlled |
| **Operated by ODL** | Convenience infrastructure: Data Pipe, Context Gateway | ODL (optional in principle — see the note below) |
**The role of ODL.** The protocol is designed to work without ODL — the direct SDK path uses only permissionless surfaces. ODL operates convenience infrastructure on top: the **RPC gateway**, which sequences transactions and anchors them to L1 (with deliberately bounded powers — it cannot redirect funds), and the **Context Gateway**, an unprivileged commercial app (OAuth, USD billing) that anyone could replicate, which enforces revocation immediately for its own customers. Decentralizing the sequencer is on the roadmap.
## Explore the protocol
The end-to-end builder guide: request, approve, read, and pay.
The onchain core: identity, permissions, fees, schemas, files, and the settlement path.
The scope-native access primitive: format, lifecycle, verification.
The escrow that funds and settles protocol fees.
The user's access engine — where grants are enforced and data is served.
Threshold key release on data access, so no single party can decrypt.
Pooled privacy-preserving jobs over DataDAO data, as an application layer.
Vana L1, validators, contracts, and the VANA token.
## Status
Where each part stands today:
* **Live:** collection (connectors, desktop app), encrypted storage, the core onchain primitives (identity, permissions, fees, schemas, files), the DP RPC, the Personal Server, and grant-gated access.
* **Rolling out:** scope-native permissions and the per-grant fee escrow (live on the Moksha testnet, moving toward mainnet), and Protocol-Governed Encryption (PGE).
* **On the roadmap:** the provenance commitment slot, bring-your-own-compute (a user-controlled compute environment), a faster settlement base, and pooled confidential compute.
Each reference page notes the relevant status in a short callout.