Hello everyone. I’m Vijon Baraku, a third-year PhD student at the University of York working on personal data sovereignty, and I’ve spent the past months as an intern at Nethermind, building a privacy-preserving marketplace for personal data on Aztec. I’ve worked closely with Conor, Artem, and John, who some of you in the Aztec world know.
This post is to introduce the project, walk through what’s built and what’s designed, and open a thread for discussion.
Why this project
The data broker market is worth around $280 to $300 billion.
The people who generate the data see almost none of this.
Most don’t even know their data is being traded: every fitness app, browser, and location-tracking permission feeds aggregation pipelines they have no visibility into. Decentralised data marketplaces like Ocean and Vana have tried to give individuals a way in, but the underlying infrastructure works against them.
On transparent chains, the data may be encrypted but everything around it is public: who listed, when, in what category, who bought, how often, at what price. For personal data (health records, location history, financial behaviour) that metadata trail is itself sensitive, and a transparent ledger of someone’s data sales becomes its own privacy problem.
A marketplace where individuals are genuinely the sellers needs three properties at once:
- Cryptographic provenance so buyers won’t pay for fabricated data.
- Privacy so sellers aren’t exposed by the act of selling.
- Atomic settlement so neither side gets defrauded.
Aztec is the first environment with a private smart contract model that fits this combination cleanly.
What the marketplace is
Two products in one marketplace.
Sell your data. Individuals list data they hold (Apple HealthKit, Garmin, Oura, Fitbit) with a cryptographic attestation of provenance, and sell it under an atomic escrow. Small structured data fits fully on-chain; larger datasets sit in off-chain storage and are unlocked atomically against payment.
Sell a query on your data. Instead of releasing the data, sellers list query rights against it. Buyers pick a permitted query type from a catalogue, pay, and receive only the result. The seller’s data never leaves their device. The marketplace contract verifies an off-chain UltraHonk proof of the computation via verify_honk_proof and releases payment atomically.
The first use case is personal health and wellness data, but the architecture is generic: any data category with an attestable source fits.
What’s built
Tier 1 (sell your data, small structured) is implemented and demoed end-to-end. The marketplace has six external functions and three custom note types (ListingNote, EscrowNote, DataNote), with a separate AttestorRegistry contract for registered attestor public keys. A web client runs a PXE in the browser. E2e tests cover the happy path and four failure modes.
Listings require an ECDSA P-256 signature from a registered attestor (verified inside the private function via std::ecdsa_secp256r1::verify_signature), with Apple HealthKit’s CMS-signed exports as the MVP attestor. Delivery is atomic: a single private function recomputes the content hash, pops the matching ListingNote and EscrowNote, creates the buyer’s DataNote, and releases payment in one transaction. Any breach reverts. Refund is available after the deadline if delivery never happens. The public listing index holds minimum metadata only, no seller or buyer identity on-chain.
4 diagrams showcase the full Tier 1 flow in detail:
What’s designed
CKR (Committed Key Reveal) for off-chain datasets, and C2D (Compute-to-Data) for query-rights sales. Both have detailed designs, neither is implemented yet.
CKR handles datasets too large to fit in Aztec notes (months of raw wearable data). The seller encrypts the dataset once under a random key K to produce ciphertext C, uploads C to content-addressable storage, and commits Poseidon2(K) and hash(C) on-chain. A listing-time ZK proof binds K, the ciphertext, and the attested plaintext. To claim payment, the seller reveals K in a transaction that atomically verifies the commitment, delivers K to the buyer in a private note, and releases escrow. Same K is revealed to every buyer (explicit trade-off: no leak traceability). Storage layer landed on Arweave canonical and Filecoin Onchain Cloud secondary.
C2D lets sellers sell query rights without releasing the data. Sellers commit their dataset as a Merkle-rooted sorted structure signed by an attestor. The marketplace holds a public catalogue of permitted query types, each pinned to a specific compiled circuit’s VK hash. Sellers pick which entries they support on their listing. Buyers lock payment for a permitted entry, the seller’s client computes locally and produces an UltraHonk proof binding the result to the committed dataset, the contract verifies via verify_honk_proof and releases payment. For datasets where a single circuit won’t fit on consumer prover hardware, queries chunk across leaf and aggregator circuits, mirroring the protocol’s own parity-root and tx-merge patterns.
The genuine differentiator of pure-ZK on Aztec is the trust model: the seller is the only party that ever holds the data and is also the prover. No third-party compute network, no honest-minority assumption, no hardware to trust. The narrow cost is that supported queries must fit in a Noir circuit on the seller’s hardware, and cross-seller pooled queries (cohort statistics, federated learning) sit outside what ZK alone can do.
What’s next
The headline next step is a C2D POC: one catalogue entry running end-to-end, from a committed dataset on the seller side through to a verified result and payment release on the buyer side. The plan to get there breaks down as follows.
- Query catalogue specification. Which classes of computation make the cut for the first catalogue and which don’t. Trivial aggregates (sum, mean, max, conditional averages) compose cleanly under chunked aggregation. Some classes need algebraic restructuring to compose at all (variance via the one-pass identity rather than the textbook two-pass form). Some are genuinely hard under chunking and need approximation algorithms (medians and percentiles via sketches like t-digest). Federated learning sits outside the practical envelope and stays flagged as such.
- Benchmark a representative catalogue entry. The proving-time numbers in the design so far are envelopes, not measurements. A representative entry (average over window, say) wants real numbers on consumer hardware before the catalogue locks.
- Worked example end-to-end. Trace one entry from listing through delivery in implementation-level detail: dataset commitment structure, listing-time circuit, buyer purchase flow, proof generation, on-chain verification, result delivery. This is the bridge between design and code.
- POC implementation. One catalogue entry shipped end-to-end, with the orchestration glue (chunk proof generation, aggregator coordination, submission, verification, result delivery to the buyer).
In parallel, Tier 1 has a small set of hardening items (partial notes for seller and buyer addresses in delivery and refund, real App Attest integration via an off-chain attestor service, HealthKit import pipeline, backend coordination service to replace the localStorage relay). These are tracked but not on the critical path for the research direction.
Repo: GitHub - NethermindEth/aztec-data-marketplace · GitHub
Any feedback is welcome and I’d be happy to share the full design documents for anyone interested.
Vijon Baraku