Security model
Vana’s security rests on three independent controls, so that no single component has to be trusted on its own:- On-chain consent record. Grants are recorded on Vana L1: permission state is tamper-evident and publicly verifiable, and changes only under the data owner’s authority — the owner’s wallet, or a server the owner has registered. This is the source of truth for who may access what.
-
Client-side access enforcement. The component that checks access — the Personal Server — runs on the user’s own device (bundled in the desktop app, or a browser tab today; a user-owned cloud compute environment in the future), not on Vana infrastructure. On every request it authenticates the caller as a registered grantee (a valid
Web3Signedsignature), checks that an active grant covers the requested scope, returns only that scope, and logs the access. A request without a valid signature and an active, in-scope grant is rejected. - Encryption under user-held keys. Data is encrypted with keys derived from the user’s wallet signature (HKDF-SHA256); Vana never holds those keys, so storage and gateway infrastructure hold only ciphertext.
Where your data lives
Plaintext user data lives in two environments: the user’s own — their device, or the Personal Server they run — and an application the user has explicitly granted access to. Storage holds only ciphertext; the protocol’s records hold pointers and metadata (owner, scope, timestamps, sizes, and content hashes) — never plaintext or keys.
The Personal Server is the component that works with plaintext — and it always runs client-side, on the user’s own device: bundled in the desktop app (Full) or as a browser tab (Lite). Both forms keep the data and the keys on the client; a user-controlled hosted form is a future option. Because the Personal Server works with plaintext locally, the user’s device is the security boundary for that copy: the decrypted working data, collector browser profiles, and any storage-backend credentials (such as cloud OAuth tokens) live on the device and are protected by it. Storage backends and on-chain records never contain plaintext or keys, so a compromise of storage or the gateway does not by itself expose user data.
Smart contract governance
Core contracts (DataPortabilityPermissions, DataPortabilityServers, DataPortabilityGrantees) are upgradeable through governance with timelocks. Contract source code is verified on the block explorer, and contracts go through the audit program.
User-controlled revocation
Users can revoke any grant at any time. Revocation is recorded immediately at the gateway (DP RPC), so subsequent gateway-mediated reads are refused; direct integrations enforce against the grant’s on-chain state. No builder or protocol operator can re-grant access on the user’s behalf. See Grants & Permissions for details.Data collection security
Connecting a data source imports the user’s own data from a platform they use into their Personal Server. Where that collection runs depends on whether the data is behind a login, and that split is a security boundary: data behind the user’s login is collected on their own device, while Vana-operated infrastructure only ever handles publicly available data. Either way, collected data lands in the Personal Server before any storage, and the user’s credentials are never sent to Vana. The two paths:
Server-side collection carries no user credentials or session, so it can only reach data that is publicly accessible without a login — anything behind the user’s login is simply unreachable on that path and is collected on the user’s own device via the desktop app instead. Collected data always lands in a Personal Server before storage; the infrastructure is never a place data lives. See Collection & apps.
The desktop app
For a user’s private data that requires a login, the desktop app runs collection locally on the user’s device. Data and session material stay on the machine — only the encrypted data the user chose to collect is synced.- Reuses the user’s existing browser session. So the user doesn’t have to sign in again, the app can drive their installed browser and its logged-in session on the device. Where a source still needs a login, the connector prompts for it and submits it directly to the source’s own login page — Vana never receives or stores those credentials.
- Runs on the user’s device. Connectors execute in a Playwright-controlled browser under the user’s home directory (
~/.vana/desktop), with a separate profile per connector. Session state is stored locally on the machine. - Sessions are local and clearable. Stored sessions live on the device so the user isn’t re-prompted each time; the app lists every stored session and lets the user clear any of them at any time.
- User-initiated. Collection — and any continuous sync the user enables to keep a source up to date — starts only when the user initiates it and can be stopped at any time.
Connector security
The scripts that perform extraction — connectors — are the part of the system that touches third-party sites and runs with the user’s browser session, so they are open source and reviewable.- Open source, maintained by the Vana core team. Every connector lives in the public
vana-com/data-connectorsrepository, so anyone — a user, a builder, or a security team evaluating an integration — can read exactly what a connector does before relying on it. The connector set is maintained by the Vana core team, and every contribution — including a platform publishing a connector for its own data — goes through a security and usability review before it is included. - Declared scope. Each connector declares the source and the scopes and schemas it produces; the user approves the requested scopes before collection, and the connector code is public for review.
- Reviewed before inclusion. Connectors enter the official set through pull-request review in the public repository, with validation tooling, rather than being loaded arbitrarily at runtime. See Add a connector.
- Version-pinned distribution. The official connectors the desktop app ships and updates are pinned in a lockfile and verified against a signature-and-checksum connector index published from the repository’s releases, so an official connector cannot silently change between releases. The app can also run user-installed connector overrides; those are user-supplied code and should be treated as such.
Encryption & keys
Encryption keys are derived from the user’s wallet signature; Vana does not generate, hold, or escrow them.- Per-scope keys, derived from the wallet. Each scope’s encryption key is derived via
HKDF-SHA256(master_key_material, "vana", "scope:{scope}"), where the master key material comes from a wallet signature. These derived scope keys are handled inside the Personal Server and are never sent to or stored by builders or Vana. - OpenPGP at rest. Each scope is encrypted as a single OpenPGP message — the file envelope (scope, timestamp, and data) is one encrypted blob. Storage holds that ciphertext blob plus routing metadata (owner, scope, timestamp, size, content hashes), never the plaintext or keys.
- Signing material stays with the user. A Personal Server needs only the master-key signature, not the wallet’s private key — and since every live Personal Server form runs on the user’s own device, that signature never leaves the client either.
- The Personal Server is the decryption point today. It decrypts only to serve a request backed by a valid, unrevoked grant, and only for the covered scopes. With Protocol-Governed Encryption (PGE) the grantee instead receives a per-request key and decrypts the data itself — the grant a builder integrates against is unchanged.
Access & consent
External access to a user’s data is authorized by an explicit, wallet-signed grant, re-checked on every request — there is no “verify once, access forever.” (The owner and local management/control-plane paths authenticate separately.)- Scope-native grants. A grant authorizes a specific grantee to read specific data types (
source.data_type), not a whole account. It is revocable at any time and can be given a bounded expiry (the safer default; a grant may also be standing consent that lasts until revoked). Grants are signed with EIP-712, so consent is cryptographically verifiable, and are recorded on Vana L1. - Verified on every request. Builders read from a Personal Server using signed HTTP requests (
Authorization: Web3Signed). Each signature is bound to the specific server, method, path, and request body, and carries issued-at and expiry timestamps, so a captured request cannot be used against a different server, method, path, or body, or after it expires. (The signature is short-lived but carries no nonce, so identical replay within its lifetime is not separately prevented.) The server validates the grant on every request — registered grantee, unrevoked, unexpired, scope covered — not just at setup. See Personal Servers → Builder data access. - Agents are bounded by the same grants. The Personal Server’s MCP interface lets AI agents work with user data under exactly the same grant permissions as any builder — a grant is the ceiling on what an agent can reach, and revocation applies identically.
- Access is logged for the user. The Personal Server records an access log of successful scope reads that the user can review.
- Revocation the user controls. A user can revoke at any time. Where the Context Gateway serves data, revocation stops future reads immediately, even before any on-chain confirmation; direct integrations enforce against the grant’s on-chain state. Revocation blocks future access — data an application already received while its grant was valid is governed by that application’s own terms, as with any permissioned-data platform.
Audits & verification
Independent audits and independent verification play different roles:- Third-party audits. Protocol smart contracts are audited by independent security firms (Nethermind, Hashlock). Completed reports cover earlier protocol components; an audit of the current data portability contracts has been commissioned and will be published when it concludes. See Audit reports.
- What you can verify yourself, today. Several properties don’t require trusting an audit — or Vana: connector code is public and auditable line by line; permission state is anchored on Vana L1 and publicly inspectable; contract source is verified on the block explorer; and the key-derivation scheme is fully specified.
- What the architecture limits. The user-held-key design bounds what any single compromised — or unaudited — component can expose: storage backends and protocol infrastructure never hold both ciphertext and keys.
Responsible disclosure
If you believe you have found a security vulnerability in Vana contracts or infrastructure, report it privately. Responsible disclosure is appreciated; reports are acknowledged and addressed as promptly as possible. Email: dev@vana.org When reporting, please include:- Affected component or contract (and version or commit if known)
- Steps to reproduce, with as much detail as possible
- Impact and severity, if you have assessed it
- Any relevant logs or proof-of-concept