Skip to main content
Most of the protocol is about an individual user granting a builder access to their own data. Confidential compute is the complementary pattern: running privacy-preserving jobs over pooled data from many users — the DataDAO model — inside a network of trusted execution environments. This is an application built on top of the protocol, not a requirement of it. The protocol stands on its own for individual data access; pooled compute is one thing a builder can choose to run, interoperable with the same identity, permissions, and storage.

​
The TEE network

Pooled compute runs on a network of confidential-compute TEEs. A TEE decrypts data only when a job is approved onchain, runs approved code over it, and returns results — without the operator, or the builder, ever seeing the raw data. This confidentiality rests on the integrity of the hardware enclave and its attestation, which places trust in the hardware vendor.

​
The three stages

StageWhat it does
Data IngestValidates contributed data and admits it to a pool, recording contribution onchain
Data ComputeRuns privacy-preserving jobs over the pooled, encrypted data inside TEEs — raw data never leaves the enclave
Data AccessRuns query jobs over the pooled dataset and returns only results (e.g. aggregates, a trained model)
Because the job runs inside the enclave, the approved computation can apply any data processing before anything is returned — detecting and redacting personally identifiable information, anonymizing or aggregating records, or adding differential-privacy noise. A researcher can, for example, train a model over many users’ contributed data and receive only the result the approved job emits — not individual raw records. The privacy of a result depends on the approved job applying the right processing, so the approval/review step is the real control — for example, applying differential privacy or output bounds when training models over the pool.

​
How it interoperates

  • Same identity — contributors and consumers are the same wallet-based identities the rest of the protocol uses.
  • Same permissions model — a job runs only when access is approved onchain.
  • DLP contracts on the DP RPC coordinate pools, contributions, and access.
  • Data added through individual portability can later be contributed to a pool — the two paths share storage and identity.
  • Verifiable contribution — each contribution carries metadata and a proof of contribution (see Provenance): a commitment to the data and an attestation of where it came from, so a pool can verify a member contributed eligible, genuine data before it is admitted — without the pool seeing the raw data.

​
Building a DataDAO

A builder creates a DataDAO with the same tools as any other integration: the SDK, whose functions call the DP RPC — there is no special chain access to wire up. The DLP contracts coordinate the pool itself: membership, contributions, and the decisions made over the pooled dataset. What makes this a DataDAO — and not just an app that collects everyone’s exports into its own database — is where the data and the control sit:
  1. Members port data the normal way. Each contributor’s data is collected under their own control, stored encrypted in their own hosted storage, and accessed through their own Personal Server.
  2. The pool never holds plaintext. Instead of granting the DataDAO plaintext access to a scope, contributed data is encrypted to a key controlled by Protocol-Governed Encryption and coordinated by the DataDAO — so access to the pooled data can only happen through on-chain permissions, never by the operator’s own hand. The DataDAO operator never sees the raw data.
  3. Contributions are verified, not inspected. Metadata and proof of contribution (above) let the pool admit genuine data without reading it.
  4. Use is decided collectively. When the pooled dataset is put to work — licensed as a dataset, or better, used to train a model — the members decide, and the approved job runs as confidential compute: the consumer receives results, and raw data never leaves the enclave.
A DataDAO can also attach economics to contribution: members receive VRC-20 proportional rights over the pooled dataset, or a contract acting for the pool pays contributors as they grant.
Status. The building blocks — TEE execution, data refinement, and querying — are in place. Pooled, multi-source confidential jobs are on the protocol’s roadmap, and the DataDAO access model described above — pool data encrypted to a PGE-controlled key, with collective decisions over its use — is a design direction whose protocol primitives are still being designed.