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:- 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.
- 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 the grantee decrypts and PGE enforces the release. Either way, decryption happens only against a valid onchain permission.
- Without PGE (today): the Personal Server returns the data directly to the builder. With 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.
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
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
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.