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.

​
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.
PrimitiveWhat it records
IdentityWallet-based identity for users, builders, and Personal Servers
PermissionsGrants — which scopes a builder may access, until when. See Grants & permissions
FeesThe escrow that funds and settles protocol fees. See Payments & fees
PGEProtocol-Governed Encryption — permissioned, no-single-holder key release. See Encryption & PGE
SchemasThe type for each scope — what shape data of a given scope takes. See Scopes & schemas
FilesPointers to a user’s stored, encrypted data objects (never the data itself)
DLP contractsThe data-liquidity-pool layer for pooled datasets. See 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.
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.
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.