Skip to main content
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.
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 Vana mainnet and the Moksha testnet. The faster settlement base (L2 / faster L1) is on the roadmap.

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

​
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.
Settlement operator. The RPC gateway sequences and verifies writes, anchors them to L1, and settles escrow fees. It can collect only fees an account has funded and cannot redirect balances. Moving to an L2 or faster-block-time base with a decentralized sequencer set is on the roadmap.