Data Procurement Network
DPN Data Procurement Network · protocol draft v0.1

I have data. Who wants it?I need data. Who can supply it?

DPN is an open, decentralized procurement network for AI data. Buyers publish machine-readable requirements. Suppliers compete to satisfy them. Independent validators verify the result. Every completed deal leaves a signed record of provenance, licensing, validation and settlement.

No native token. No DPN blockchain. No central database that somebody owns.

A portable transaction record tying the exact dataset, validation evidence, license, settlement and counterparties together.
Watch · 4:38 · narrated

The protocol, explained in under five minutes

See how a buyer request moves through supplier matching, validation, acceptance, licensing, settlement, witness checkpointing and Bitcoin anchoring.

DPN explainer · Protocol Bundle v0.1 Download MP4 (21 MB)
What DPN makes possible

State exactly what you need. Let qualified suppliers compete for it.

DPN allows AI buyers to publish precise data requirements and let qualified suppliers compete to fulfill them.

Speech

20,000 hours of licensed conversational Arabic

  • speaker diversity
  • recording quality
  • metadata
  • transcription accuracy
Robotics

2 million teleoperation trajectories for warehouse manipulation

  • sensor configuration
  • task types
  • labeling
  • quality thresholds
  • commercial training rights
Medical imaging

500,000 appropriately consented medical images

  • modality
  • metadata
  • demographic coverage
  • de-identification
  • provenance
  • permitted AI uses

Suppliers compete to satisfy the request. Independent validators verify the result. DPN records the transaction.

Illustrative requests only. These datasets are not currently available on the network.

Core flow

From a stated need to a receipt anyone can verify

The primary procurement object is a DataRequest. The buyer commits to the acceptance rules before any supplier submits an offer, so nobody can move the goalposts afterwards.

  1. 1DataRequestBuyer states the spec, the rights required and a maximum price.
  2. 2DataOfferSupplier commits to an exact dataset by Merkle root.
  3. 3ValidationValidators run the checks in the AcceptancePolicy.
  4. 4AcceptanceAccepted, partially accepted, rejected or disputed.
  5. 5LicenseA license commitment is bound to the accepted data.
  6. 6SettlementPaid over whichever rail the parties choose.
  7. 7DataReceiptFinal when both counterparties sign the same body.
Architectural principles

Decentralized coordination without blockchain overhead

Commercial truth comes from signatures, object relationships, validation evidence and counterparty commitments. Ordinary transactions do not need global consensus.

Native token

None is required. Companies can earn from procurement fees, validator routing, hosted relays, managed procurement, analytics and dispute services.

DPN blockchain

Bitcoin serves only as an external timestamp. DPN is designed to anchor finalized checkpoints to Bitcoin daily. Bitcoin processes no DPN transactions.

Central database

Relays store, forward and index signed events, and relay operation is permissionless by design. Relays move signed facts; they do not decide truth.

Datasets on the wire

Data stays in supplier infrastructure, cloud storage, repositories or controlled data rooms. DPN carries commitments, capped at 256 KiB per event.

Who takes part

Six roles, each with a narrow job

Buyer

Publishes requests and funds successful procurement.

Supplier

Owns, creates or sources data and submits offers against open requests.

Validator

Sells verification as a service. Paid for running checks correctly, whether the result is pass or fail.

Auditor

Re-checks a sample of validator decisions to catch collusion, false accepts and false rejects.

Relay

Untrusted transport. Distributes and indexes signed events, returning a signed receipt for each one it accepts. Does not decide commercial truth.

Witness

Attests to historical inclusion in the append-only transparency log. Does not determine whether commercial claims are true.

History you can prove

A cumulative transparency log, signed by 5 of 7 witnesses

The initial network is designed around seven founding witness organizations with a 5-of-7 checkpoint threshold, and the initial protocol profile proposes hourly checkpoints. Any two groups of five share at least three members, so with up to two faulty witnesses at least one honest witness sits in both.

Each checkpoint is a provable append-only extension of the one before it, using a Certificate-Transparency-style Merkle tree. A witness that signs two conflicting roots has produced objective evidence of its own misconduct.

A proof package holds the receipt, signatures, inclusion proof, checkpoint and Bitcoin anchor. It can be verified offline, without contacting the operator that handled the deal.

Inclusion assurance levels
  1. LOCAL signed by the author
  2. RELAYED accepted by a relay
  3. DISTRIBUTED held by 3 or more independent relays
  4. WITNESSED observed by a witness
  5. INCLUSION-ASSURED 5 witnesses promise inclusion
  6. CHECKPOINTED in a finalized checkpoint
  7. BITCOIN-ANCHORED externally timestamped
Identity and trust

Three layers of trust, none of them owned by DPN

DID

Identity is cryptographic.

Organizations sign with DIDs (did:webvh), using scoped operational keys that rotate without breaking old signatures.

Verifiable Credentials

Credentials are attested.

Roles and qualifications travel as credentials, so a request can require a speech-validation credential without naming a validator.

DPN history

Reputation is observed.

No official score. Any indexer can rank participants from the same signed history: jobs, audits, disputes.

A signature proves who made an offer. It does not prove they hold the rights to sell the data, so rights evidence stays explicit: consent documentation, provenance and license representations.

Settlement

Pay however you already pay

DPN records a settlement reference in the receipt and is designed to leave the money movement to payment-rail adapters.

Status

Draft protocol, v0.1

DPN is a specification in progress, and no part of the network is deployed yet. It is designed to launch as a federated consortium of seven witness organizations drawn from buyers, suppliers, validation companies, universities and infrastructure providers. The consortium exists so that nobody owns the network.

Permissionless at the relay layer, permissioned but plural at the witness layer, competitive at the validator layer, and cryptographically sovereign at the actor layer.
Build order
  1. Freeze primitives: canonical JSON (RFC 8785), Ed25519, test vectors
  2. Core event library, then DID and key layer
  3. Reference relay and client SDK
  4. Procurement schemas and dataset manifests
  5. Validator marketplace and auditing
  6. Transparency log, witness service, Bitcoin anchoring
  7. Independent monitor, private events, genesis tooling

First milestone: one request carried end to end, from publication to a proof package that a standalone verifier checks offline.

Exists today
  • Draft protocol specification, v0.1 (nine documents)
  • Explainer video and this site
Designed, not yet deployed
  • Reference relays and client SDK
  • Validator and auditor marketplace
  • Founding witness consortium and transparency log
  • Bitcoin checkpoint anchoring
  • Standalone proof verifier
Participate

Help build the founding network

DPN is being designed as an open procurement network for AI data. We are looking for organizations interested in participating in the initial network as buyers, suppliers, validators, infrastructure operators, researchers or founding witnesses.

The network needs
  • Buyers
  • Data suppliers
  • Validators
  • Auditors
  • Relay operators
  • Witness organizations
  • Research partners
  • Infrastructure partners