> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vana.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Encryption & PGE

> Protocol-Governed Encryption — permissioned key release on data access, with no single party ever holding the key.

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.

```mermaid theme={null}
flowchart TB
    data["user data"]:::sdk -->|encrypted to| pk["PGE public key"]:::protocol
    g["grantee with onchain permission"]:::neutral -->|requests release| holders["t-of-N holders<br/>each return a share<br/>(no one holds the full key)"]:::protocol
    holders -->|per-request key, re-encrypted to the grantee's key| g
    g -.->|decrypts data; PGE never sees raw data| done["data unlocked for grantee"]:::neutral

    classDef protocol fill:#DCE4FF,stroke:#4141FC,color:#11104a;
    classDef sdk fill:#FFF3D1,stroke:#E6A700,color:#5c4400;
    classDef neutral fill:#EEF1F5,stroke:#9AA4B2,color:#1f2937;
```

1. A user's data is encrypted to PGE's **public key**.
2. A grantee holding a valid [permission](/protocol-reference/grants-permissions) 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](/protocol-reference/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.

<Info>**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.</Info>