Privacy-Preserving DAO Data Queries

What It Is

A blockchain-based system that allows users to query datasets while maintaining complete data privacy. The system combines decentralized governance (DAOs) with trusted execution environments (TEEs) to ensure that sensitive data remains protected throughout the query process.

How It Works

Query Submission Users submit SQL queries along with their public encryption keys to a smart contract. Each query becomes a proposal that requires community approval before execution.

Governance Process Each dataset has its own DAO where token holders vote on whether to approve submitted queries. The voting process is transparent and follows standard DAO governance patterns using ERC20 tokens.

Private Execution Approved queries are processed by a trusted execution environment (TEE) that:

• Fetches the dataset from Akave (IPFS) storage
• Executes the SQL query within a secure enclave
• Encrypts the results using the user's public key
• Returns the encrypted data to the blockchain

Result Retrieval Users can retrieve their encrypted query results from the blockchain and decrypt them using their private keys. Only the original requester can access their specific results.

Privacy Guarantees

The system ensures that:

• Dataset contents are never exposed outside the TEE
• User queries remain confidential throughout the process
• Query results are only accessible to the requesting user
• All data processing occurs within secure, isolated environments

Technical Implementation

Smart Contracts: Built on Oasis Sapphire for confidential contract execution Data Storage: Datasets stored on Akave using IPFS for decentralized, immutable storage Governance: OpenZeppelin Governor contracts with ERC20 token-based voting Frontend: Scaffold-ETH framework for user interaction Security: End-to-end encryption with TEE-based query execution

Key Features

• One DAO per dataset, allowing specialized governance rules
• Configurable approval thresholds based on dataset sensitivity
• 30-day proposal expiration to prevent stale requests
• Role-based access control for administrative functions
• Complete audit trail of all queries and approvals

The system addresses the challenge of providing data access for legitimate research and analysis while maintaining strict privacy controls and decentralized decision-making.

At a high level, our system consists of a DAO smart contract on Oasis Sapphire and one or more Trusted Execution Environments (TEEs) that work in concert to manage a private dataset on Akave and to execute approved SQL queries against it. By combining EVM-compatible logic with Oasis’s confidential-compute primitives, we achieve both interoperability with other EVM chains and strong data confidentiality guarantees.

DAO (Decentralized Autonomous Organization)

Deployment & Privacy The DAO is implemented in Solidity and deployed on the Oasis Sapphire network, which provides native support for secret storage. Those secret storage primitives hold the access credentials (API keys, encryption keys, etc.) needed to read from and write to the Akave S3 interface. Because Sapphire is EVM-based, the DAO bridged to other EVM-compatible chains in the future through message passing bridges. Primary Responsibilities

1. Query Governance External parties submit “query proposals” that specify:
   • A SQL query to run over the dataset in Akave (e.g., SELECT statements).
   • A one-time public key (or key identifier) that will be used to encrypt the query result. Once a proposal is on-chain, the DAO initiates a voting process. If the vote reaches quorum, the proposal’s status flips to approved, and a TEE (or set of registered TEEs) picks up the proposal.
2. Data Expansion / Upload Governance Anyone can propose adding new data to the managed dataset by submitting:
   • An “upload proposal” that contains an IPFS CID pointing to a data file. After on-chain voting reaches quorum, the upload proposal becomes approved, and a TEE fetches the data from IPFS and pushes it into Akave via the S3 interface. This ensures that only community-vetted datasets ever enter the private repository. TEE Registration If a participant wants to run TEE compute nodes, they submit a “TEE registration proposal.” This proposal includes information like the TEE’s attestation report (e.g., a TDX quote) and any networking endpoints required to send voting tallies or fetch data. Once approved on-chain, that TEE is whitelisted to pull work (approved proposals) and to push back results.

2.** TEE (Trusted Execution Environment)** Confidential Compute Foundations Each TEE is built atop Oasis’s ROFL stack, making use of Intel TDX (Trust Domain Extensions) for hardware-level isolation. When a TEE is registered, it generates a public-private key pair and provides an attestation report (via TDX) to the DAO. The DAO stores only the public portion (in encrypted form if desired), so that, later, results can be encrypted to that key. Because TDX assures that code running inside the enclave cannot be tampered with or inspected, both the dataset and the access credentials remain confidential throughout execution. Proposal Monitoring & Execution TEEs continuously listen for state changes (newly approved proposals) on the DAO contract. There are two main workflows:

1. Upload Workflow
   • Upon detecting an approved upload proposal, the TEE fetches the file from the specified IPFS location.
   • The TEE may perform any pre-processing steps (e.g., schema validation or de-duplication) inside the enclave.
   • Once validated, the TEE uses the DAO’s secret S3 credentials to write the new data into Akave.
   • Finally, the TEE marks the proposal as “consumed” by invoking a transaction on the DAO, completing the upload cycle.
   1. Query Workflow
   • When a query proposal is approved, the TEE retrieves the corresponding SQL statement, the user’s public key, and any other parameters.
   • The TEE loads the relevant dataset (or partitions) from Akave into an in-enclave, in-memory OLAP engine (we use DuckDB because it excels at single-node SQL).
   • After running the SQL query, the TEE encrypts the result set using the public key provided in the original proposal (so that only the proposer can decrypt it). We rely on envelope encryption: the TEE generates a one-time symmetric key, encrypts the query result with it, then encrypts that symmetric key with the proposer’s public key.
   • Finally, the TEE submits the ciphertext (and any required metadata, such as a hash of the plaintext for auditability) back to the DAO by “consuming” the query proposal. At this point, the DAO stores the encrypted payload on-chain or off-chain (depending on size) and marks the request as fulfilled. Flexible Execution Implementations Although DuckDB is our default for OLAP queries, the TEE abstraction can be extended to support:
   • Graph Processing: TEEs running a light-weight graph engine (e.g., Neo4j or TigerGraph in enclave mode) for more advanced analytics.
   • Machine Learning Inference: A minimal TensorFlow-Lite or ONNX runtime inside TDX for privacy-preserving predictions.
   • Custom Business Logic: Containers or WASM modules that implement proprietary transformations, as long as they fit within the TDX memory constraints. This flexibility allows us to tailor each TEE to the exact computational needs of a given proposal—whether that’s a simple SELECT, a complex join over massive tables, or even a small ML inference task.