Security is not a layer on top of Vana’s data portability stack; it is the reason the stack is shaped the way it is. User data is encrypted under keys only the user controls, every access is authorized by a wallet-signed grant, and no single component — including Vana’s own infrastructure — has to be blindly trusted. This page describes how that works end to end; completed third-party audits are listed on the Audit reports page.
Trust and risk. No architecture or audit guarantees the absence of vulnerabilities. If you integrate with or rely on the protocol, conduct your own due diligence and understand the risks.
Security model
Vana uses a defense-in-depth architecture. Three independent layers protect user data — a compromise in one layer does not expose plaintext data:
-
Chain-level. Grants are recorded on Vana L1 — permission state is tamper-proof and publicly verifiable. No central party can modify access. Only the data owner can create or revoke a grant.
-
Server-level. Personal Servers independently verify every request: signature validation, grant checking, scope matching, and access logging. Even if a malicious request reaches the server, it is rejected unless it carries a valid signature from a registered builder with an active grant for the requested scope.
-
Encryption-level. Data is encrypted at rest with user-derived keys (HKDF-SHA256 from wallet signature). Storage backends never see plaintext. Even a compromised storage backend yields only encrypted blobs that cannot be decrypted without the user’s wallet signature.
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 backends and the protocol’s on-chain records hold only ciphertext and pointers, never plaintext or keys.
| Stage | Where | What is exposed |
|---|
| Collection | The user’s device (desktop app), or a session run on the user’s behalf on Vana-operated infrastructure (web app) | Plaintext — on the user’s device, or transiently in the collection session |
| Personal Server | Works with plaintext locally to organize and serve data; encrypts each scope before sync | Plaintext, in the user’s environment |
| At rest | Storage backend — encrypted OpenPGP blobs; the protocol holds only pointers (the Files primitive) | Nothing — ciphertext only |
| Consent | A grant recorded on Vana L1 | Metadata only, never data |
| Access | The Personal Server validates the grant and serves the granted scope over an authenticated channel | Only the authorized application |
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 takes effect immediately at the DP RPC level and is synced to the chain asynchronously. No builder or protocol operator can prevent or delay revocation. See Grants & Permissions for details.
Data collection security
Connecting a data source means exporting the user’s own data from a platform they already use. Because this step touches real accounts, it carries the tightest controls in the stack. Collection always happens on the user’s behalf and under the user’s control — credentials never leave the user, and collected data lands directly in the user’s own Personal Server before any storage. There are two paths, by where collection runs:
| Path | Where it runs | Used for |
|---|
| Client-side (desktop app) | The user’s own device (Playwright connector) | Sources that need the user’s authenticated session |
| Server-side (web app) | A session on Vana-operated infrastructure, on the user’s behalf | Convenience collection that lands in the user’s Personal Server |
The desktop app
For data behind the user’s login, the desktop app runs collection locally. Its session handling is designed so that installing the app never puts the user’s existing browser or other logins at risk:
- A dedicated, bundled browser — never the user’s own. The app uses its own browser runtime for collection. It does not read, attach to, or share state with the user’s installed browsers, their profiles, cookies, or logged-in sessions.
- Isolated profile per source. Each connected source gets its own separate browser profile on the user’s machine. One connector cannot see another connector’s session.
- The user logs in — the app doesn’t. Authentication happens directly on the source’s own login page. The user enters their password and completes any 2FA or CAPTCHA themselves. The app never asks users to enter source credentials into Vana forms and never persists credential material.
- Sessions stay on-device and under user control. Login sessions are persisted locally only so the user doesn’t have to re-authenticate on every refresh, and the app lets the user view and clear any stored session at any time.
- Single-source scope, user-driven. A connector navigates only the source it was built for, and collects only the data types shown to the user before collection. Collection — and any continuous sync the user turns on to keep a source up to date — is user-enabled and can be stopped at any time.
Connector security
The scripts that perform extraction — connectors — are the one part of the system that touches third-party sites, so they are kept transparent by design.
- Open source and community-controlled. Every connector lives in the public
vana-com/data-connectors repository. Anyone — a user, a builder, or a security team evaluating an integration — can read exactly what a connector does before relying on it, and anyone can contribute one. Platforms can also publish connectors for their own data.
- 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 desktop app ships with a lockfile pinning the exact version of every connector it uses, resolved against a signature-verified connector index published from the official repository’s releases. A connector cannot silently change underneath users between app releases.
Teams integrating Vana are welcome to review — and pin — the specific connectors their integration relies on. For most integrations that is a short, easily auditable list; a security team can read every line of the collection code their users will run before recommending the integration.
Encryption & keys
Keys belong to users; every cryptographic guarantee traces back to the user’s wallet.
- 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 entire file envelope (scope, timestamp, and data) is one encrypted blob, with no plaintext metadata stored alongside it. Storage backends hold only ciphertext.
- 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.
Full detail: Storage & Encryption.
Access & consent
Every data access is authorized by an explicit, wallet-signed user decision — there is no implicit access and no “verify once, access forever.”
- 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 — a captured request cannot be replayed elsewhere or later. 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 keeps an access log the user can review, so every data access event is visible to the person the data belongs to.
- Revocation the user controls. A user can revoke at any time. Where the Context Gateway serves data, revocation stops future reads immediately, even before on-chain confirmation; the revocation is anchored on-chain as the durable record that direct integrations enforce against. 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 in the stack’s assurance story:
- 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; the key-derivation scheme is fully specified; and the desktop app’s isolation behavior (dedicated browser, per-source profiles, local sessions) is observable on the user’s own machine.
- Architecture over assurances. The user-held-key design limits what any single compromised — or unaudited — component can expose: storage backends and protocol infrastructure never hold both ciphertext and keys.
Teams evaluating an integration are welcome to reach out to dev@vana.org for a technical walkthrough of the security model for their specific use case.
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
Receipt is acknowledged as soon as possible; a more detailed response follows once the issue has been reproduced or triaged. Please do not disclose findings publicly until the issue has been addressed. 
