Skip to main content
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 an optional application a builder can choose to run.
Building an app on Vana? Start with the 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

​
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, which holds only ciphertext.
  2. When a builder presents a grant, the Personal Server decrypts the covered data and returns it directly to the builder. With Protocol-Governed Encryption (PGE), the grantee instead receives a key from PGE and decrypts the data itself. Either way, decryption happens only against a valid onchain permission.
  3. The grant is recorded on-chain, and the read is recorded in an access log the user can review.
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. Once data is returned to a builder, the builder’s copy is outside the grant and the access log.

​
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 Open Data Labs (ODL), green = community connectors.
The role of ODL. The protocol does not depend on ODL: the direct SDK path uses only permissionless surfaces. ODL operates the RPC gateway, which sequences transactions, anchors them to L1 and cannot move escrowed funds, and the Context Gateway, an optional service for OAuth and USD billing. Decentralizing the sequencer is on the roadmap.

​
Explore the protocol

Build a Vana App

The end-to-end builder guide: request, approve, read, and pay.

Protocol — DP RPC

The onchain core: identity, permissions, fees, schemas, files, and the settlement path.

Grants & permissions

The scope-native access primitive: format, lifecycle, verification.

Payments & fees

The escrow that funds and settles protocol fees.

Personal Servers

The user’s access engine — where grants are enforced and data is served.

Encryption & PGE

Threshold key release on data access, so no single party can decrypt.

Confidential compute

Pooled privacy-preserving jobs over DataDAO data, as an application layer.

Network

Vana L1, validators, contracts, and the VANA token.

​
Status

  • Live: collection (connectors, desktop app), encrypted storage, the core onchain primitives (identity, permissions, fees, schemas, files), the DP RPC, the Personal Server, grant-gated access, and scope-native permissions and the fee escrow on Vana mainnet and the Moksha testnet.
  • In progress: 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.