> ## 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.

# Protocol — DP RPC

> The onchain core of the protocol — identity, permissions, fees, PGE, schemas, and files, served through a fast settlement layer.

The **DP RPC** is the protocol's read/write boundary. It exposes the protocol's primitives over a fast API, verifies every mutation cryptographically, serves it immediately, and anchors it to the chain — so applications get low-latency reads and writes while the chain remains the source of truth.

Because reads and writes are served from the gateway's verified state rather than waiting on block confirmation, the interactive loop (grant → pay → read) responds in roughly **200–300 ms** — latency on par with what Web2 users expect — while the chain still provides durable settlement underneath.

Everything a builder, Personal Server, or app touches goes through this surface. The primitives behind it are the substance of the protocol.

```mermaid theme={null}
flowchart LR
    w["builder / PS / app"]:::neutral -->|"signed write (EIP-712)"| rpc["DP RPC<br/>verify → serve → anchor"]:::protocol
    rpc -->|read| r["builder / PS / app"]:::neutral
    rpc --> l1["Vana L1<br/>settlement"]:::protocol

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

## Onchain primitives

The protocol models seven primitives. Each is a purpose-built onchain record; the DP RPC is the fast path in front of them.

| Primitive         | What it records                                                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Identity**      | Wallet-based identity for users, builders, and Personal Servers                                                                       |
| **Permissions**   | Grants — which scopes a builder may access, until when. See [Grants & permissions](/protocol-reference/grants-permissions)            |
| **Fees**          | The escrow that funds and settles protocol fees. See [Payments & fees](/protocol-reference/payments-fees)                             |
| **PGE**           | Protocol-Governed Encryption — permissioned, no-single-holder key release. See [Encryption & PGE](/protocol-reference/encryption-pge) |
| **Schemas**       | The type for each scope — what shape data of a given scope takes. See [Scopes & schemas](/protocol-reference/scopes-schemas)          |
| **Files**         | Pointers to a user's stored, encrypted data objects (never the data itself)                                                           |
| **DLP contracts** | The data-liquidity-pool layer for pooled datasets. See [Confidential compute](/applications/confidential-compute)                     |

## Identity

Every participant is a wallet. A user, a builder, and a Personal Server each act under an EVM address, and the protocol authorizes actions by recovering the signer of an EIP-712 payload.

* **Users** sign grants and data operations with keys derived from their wallet.
* **Builders** register an identity (and a public key for encrypted delivery) before they can receive a grant.
* **Personal Servers** register an address and URL, and a user marks a server as trusted to act on their behalf — letting the server sign for the user's data within the scopes the user allows.

This makes consent attribution exact: the chain records which wallet granted what, to whom, and until when. The individual reads a server performs are recorded in that Personal Server's access log rather than on-chain — so attribution of *consent* is on-chain, while attribution of each *read* lives in the server's log the user can review.

## Settlement

The DP RPC already does what a rollup does: it **aggregates protocol transactions, verifies them, serves them immediately, and anchors them to Vana L1**. A verified write is available to read at once and is confirmed onchain shortly after.

The direction is to move that settlement path onto a **lower-latency base — an L2 rollup or a faster-block-time L1** — so the interactive loop (grant, pay, read) settles closer to real time. The protocol's shape does not change; only the speed and finality characteristics of the base it settles on.

<Info>**Settlement operator.** Today the **RPC gateway** plays the aggregation-and-anchoring role: it sequences and verifies writes and anchors them to L1, and settlement of escrow fees routes through it to keep on-chain accounting consistent. Its powers are deliberately **bounded** — it can collect only fees an account has explicitly funded and cannot redirect balances. Decentralizing this into an L2 / faster-block-time base with a decentralized sequencer set is on the roadmap.</Info>

<Info>**Status.** The DP RPC surface, EIP-712 verification, and L1 anchoring are live, along with the core primitives — identity, permissions, fees, schemas, and files. PGE and provenance are rolling out (see their pages). Scope-native permissions and the fee escrow are live on the Moksha testnet and moving toward mainnet. The faster settlement base (L2 / faster L1) is on the roadmap.</Info>