Skip to main content
Today, before PGE, a Personal Server’s encryption key is derived from the user’s wallet — it is created for that Personal Server from the user’s Vana Master Signature. That key encrypts the user’s data, and in this model the Personal Server is the only entity that decrypts: it returns a requested scope to a grantee as a point-in-time snapshot, so a later change or revocation never reaches the grantee. Because this key is derived from a wallet signature, the desktop app warns the user before creating the Personal Server signature and prompts them to confirm they are using the official Vana / Open Data Labs app. Protocol-Governed Encryption (PGE) changes who decrypts and what enforces it. Instead of the Personal Server decrypting, the grantee decrypts, and PGE becomes the enforcement point: the decryption key is a threshold secret split into shares across several holders, and PGE releases it — re-encrypted to the specific grantee — only when an onchain permission says so. No single holder holds the whole key. PGE governs data access: it turns “the user granted this scope” into “this grantee can decrypt this specific data,” without any single party being able to decrypt on its own.

​
How it works

PGE splits the key across N holders such that any sufficient subset (t of N) can cooperate to release it, but fewer cannot. The key is never reassembled in one place.
  1. A user’s data is encrypted to PGE’s public key.
  2. A grantee holding a valid permission asks PGE to release a key to their own key.
  3. PGE checks the permission onchain, gathers a quorum of decryption shares, and returns a per-request key, re-encrypted to the grantee — scoped to the data the permission covers, not a reusable master or scope key.
  4. The grantee decrypts that data; PGE itself only ever handles keys, never the data.
This per-request shape is what keeps expiry and revocation meaningful: a release hands over only the data covered at that moment. Reaching anything more — newer data, or data after the grant expires or is revoked — requires a fresh release, which the chain can deny.

​
Why it matters

  • Distributed trust — the key is held as shares across multiple holders, and release requires a quorum, so trust does not rest with any single holder. Committee size, threshold, and operator diversity are part of the security model.
  • Permissioned by the chain — a key is released only when an onchain permission says it should be.
  • Per-request release — each release is scoped to the request, so a grantee never receives a standing key to a whole scope. This is what makes expiry and revocation enforceable at the key layer, not just in an audit log.
  • Rotatable without disruption — holders can be added, removed, or refreshed, and the public key never changes, so data encrypted to it stays valid.
  • Key-only — PGE operates on encryption keys, not on user data; raw data never enters it.

​
Relationship to storage

PGE builds on the wallet-derived key model described in Storage & encryption: data is still stored encrypted and synced off-device unchanged, but the key that unlocks a scope for a grantee is released through PGE’s threshold process rather than by a single holder.

​
Security model

A few properties worth stating directly:
  • Quorum trust — security holds as long as fewer than the threshold of holders collude; the committee’s composition and diversity are the trust anchor.
  • Per-request scope — PGE governs future releases. Once a grantee has decrypted the data it received, expiry and revocation gate the next request, not data already delivered.
Status. The threshold cryptography, the onchain-permissioned key-release path, and encrypted local/committee backups are in place. A fully decentralized holder committee, holder rotation/resharing, and hardware-attested execution are in active development. Until PGE is the default, scopes are protected by the Personal Server’s key model.