Verida primary sources — 2026-05-14

Official properties reviewed

Verida positions itself as missing middleware for Web3 applications: identity, authentication, messaging, and private personal-data storage, rather than only public blockchain compute or public file storage.
The protocol description emphasizes a stack of servers, libraries, and SDKs that support decentralized identities plus database storage, block storage, messaging, notifications, and blockchain interoperability.
The whitepaper summary explicitly says node operators can run open-source server nodes and that users can select infrastructure providers on the network.
The product framing is not just a wallet. The summary describes a mobile Verida Wallet that acts as both a data wallet and crypto wallet, alongside developer SDKs for SSO, client access, transactions, trust, and API connectors.

Verida argues ordinary decentralized storage is insufficient for private application data because it lacks built-in encryption, user-chosen hosting, self-hosting, regulatory posture, and Web2-like performance.
User data is stored on Verida storage nodes, but the architecture allows users to determine which nodes store their data or to self-host private nodes.
Data is encrypted client-side with keys controlled on the end-user device; storage nodes only accept authenticated requests from the data owner.
Verida accounts split data into application contexts, with independent storage locations and encryption keys per context.
The default wallet policy is three storage-node replicas, with replication and recovery built into the network.
Under the hood the stack uses CouchDB plus PouchDB so encrypted user data can still synchronize across applications using familiar database replication semantics.

A Verida account can connect to multiple application contexts, each with its own storage, messaging, block storage, and notification capabilities.
Contexts are siloed from one another, so one application context cannot automatically access another context’s data.
Unlocking a context requires a signed consent message; that signature seeds deterministic symmetric, asymmetric, and signing keys for the context.
Context metadata, public keys, and service endpoints are published into the account’s DID document so other participants can discover where to route messages and which keys to use.

Verida exposes several different privacy/consent patterns rather than one flat storage API: one-off private messages, one-off data requests, application-owned silos, and ongoing synchronized access.
The docs explicitly support filtered, read-only, write-enabled, one-off, or permanent synchronization patterns, which is important because it makes data-sharing policy a first-class design surface.
The examples reveal the intended market: reusable personal-data rails for credentials, profiles, health records, social data, and other private user-controlled datasets.

Verida is useful because it separates several layers that generic data wallet or decentralized storage labels often flatten together:

Review the full PDF whitepaper and token/network-incentive details directly rather than relying mainly on the summary page.
Inspect current node-operator economics and whether provider selection is practically user-controlled or wallet-default-controlled.
Compare Verida’s DID / consent / storage stack more directly against Fission, WNFS, Bubble Protocol, Ceramic/ComposeDB, and data-wallet SSI stacks.